All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Denys Vlasenko <dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] access.2: explain how access() check treats capabilities
Date: Wed, 11 Feb 2015 14:38:03 +0100	[thread overview]
Message-ID: <54DB5B3B.5060600@gmail.com> (raw)
In-Reply-To: <54DB5A71.6080606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi Denys,

On 02/11/2015 02:34 PM, Denys Vlasenko wrote:
> Hi Michael,
> 
> On 02/05/2015 11:44 AM, Michael Kerrisk (man-pages) wrote:
>> On 09/10/2014 03:01 PM, Denys Vlasenko wrote:
>>> We have users who are terribly confused why their binaries
>>> with CAP_DAC_OVERRIDE capability see EACCESS from access() calls,
>>> but are able to read the file.
>>>
>>> The reason is access() isn't the "can I read/write/execute this file?"
>>> question, it is the "(assuming that I'm a setuid binary,) can *the user
>>> who invoked me* read/write/execute this file?" question.
>>>
>>> That's why it uses real UIDs as documented, and why it ignores
>>> capabilities when capability-endored binaries are run by non-root
>>> (this patch adds this information).
>>>
>>> To make users more likely to notice this less-known detail,
>>> the patch expands the explanation with rationale for this logic
>>> into a separate paragraph.
>>
>> Thanks, Denys. Applied.
> 
> I don't see it in git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git

Currently, I have it in a local branch. You'll get a mail
when it's released.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2015-02-11 13:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10 13:01 [PATCH] access.2: explain how access() check treats capabilities Denys Vlasenko
     [not found] ` <1410354068-6100-1-git-send-email-dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-05 10:44   ` Michael Kerrisk (man-pages)
     [not found]     ` <54D3498C.7000904-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-02-11 13:34       ` Denys Vlasenko
     [not found]         ` <54DB5A71.6080606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-11 13:38           ` Michael Kerrisk (man-pages) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DB5B3B.5060600@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.