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: Thu, 05 Feb 2015 11:44:28 +0100	[thread overview]
Message-ID: <54D3498C.7000904@gmail.com> (raw)
In-Reply-To: <1410354068-6100-1-git-send-email-dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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.

Cheers,

Michael


> Signed-off-by: Denys Vlasenko <dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> CC: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  man2/access.2 | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/man2/access.2 b/man2/access.2
> index bfd85cd..73495ad 100644
> --- a/man2/access.2
> +++ b/man2/access.2
> @@ -102,9 +102,22 @@ The check is done using the calling process's
>  UID and GID, rather than the effective IDs as is done when
>  actually attempting an operation (e.g.,
>  .BR open (2))
> -on the file.
> -This allows set-user-ID programs to
> -easily determine the invoking user's authority.
> +on the file. Similarly, for root user, the check uses the set of
> +permitted capabilities rather than the set of effective
> +capabilities; and for non-root user, the check uses an empty set
> +of capabilities.
> +
> +This allows set-user-ID programs and capability-endowed programs
> +to easily determine the invoking user's authority. In other words:
> +.BR access ()
> +does not answer the "can I read/write/execute this file?" question.
> +It answers a bit different question: "(assuming I'm a setuid binary,)
> +can
> +.I the user who invoked me
> +read/write/execute this file?",
> +with the intent to make it possible for setuid programs to not
> +allow malicious users make them read files which users shouldn't be
> +able to read.
>  
>  If the calling process is privileged (i.e., its real UID is zero),
>  then an
> 


-- 
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-05 10:44 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) [this message]
     [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)

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=54D3498C.7000904@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.