linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, "J. Bruce Fields" <bfields@fieldses.org>
Cc: mtk.manpages@gmail.com, Jan Stancek <jstancek@redhat.com>,
	linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk,
	guaneryu@gmail.com, mszeredi@redhat.com,
	Cyril Hrubis <chrubis@suse.cz>,
	ltp@lists.linux.it
Subject: Re: utimensat EACCES vs. EPERM in 4.8+
Date: Wed, 18 Jan 2017 21:17:00 +1300	[thread overview]
Message-ID: <19d8cbe2-4209-0e25-42ea-380a55104f0e@gmail.com> (raw)
In-Reply-To: <20170117210403.spl6fpzegfmir6cy@thunk.org>

On 01/18/2017 10:04 AM, Theodore Ts'o wrote:
> On Tue, Jan 17, 2017 at 02:35:57PM -0500, J. Bruce Fields wrote:
>> Where did this blog entry come from?  I've never seen the ACCES/PERM
>> distinction made that way anywhere else.  Posix says:
>>
>> 	[EACCES]
>> 	    Permission denied. An attempt was made to access a file in a
>> 	    way forbidden by its file access permissions.
>> 	[EPERM]
>> 	    Operation not permitted. An attempt was made to perform an
>> 	    operation limited to processes with appropriate privileges
>> 	    or to the owner of a file or other resource.
>> So EPERM is exactly for attempts to do things that are reserved for root
>> (or process with appropriate capabilities or whatever).

> (or process with appropriate capabilities or whatever).

Yes. POSIX makes it pretty clear here, I think. EACCES is (generally) 
about pathname permissions. (One can see this by perusing the various 
EACCES cases in POSIX.) EPERM is (generally) about other kinds of
permission denials (including Ted's "I'm sorry Dave, I can't let you
do that" cases, which are a subset of these cases). And in both cases,
superuser privilege may potentially bypass the restriction (except
for the EPERM "Dave" cases).

So, that suggests that EPERM would be the right error for denial of
permission because of the inode immutable or append-only flag. 
(Earlier, I thought EACCES would be right, but I changed my mind.) Or,
roughly, the patch under discussion made things more "correct", but
at a (small) risk of user-space breakage.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

      reply	other threads:[~2017-01-18  8:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 15:46 utimensat EACCES vs. EPERM in 4.8+ Jan Stancek
2017-01-16 15:53 ` Miklos Szeredi
2017-01-17  0:04   ` Michael Kerrisk (man-pages)
2017-01-17  4:50     ` Carlos O'Donell
2017-01-17  7:51     ` Jan Stancek
2017-01-17  7:57       ` Cyril Hrubis
2017-01-17  9:39         ` Miklos Szeredi
2017-01-17 15:43           ` Cyril Hrubis
2017-01-18  8:23           ` Michael Kerrisk (man-pages)
2017-01-31 12:09             ` Cyril Hrubis
2017-01-17  4:41 ` Theodore Ts'o
2017-01-17 19:35   ` J. Bruce Fields
2017-01-17 21:04     ` Theodore Ts'o
2017-01-18  8:17       ` 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=19d8cbe2-4209-0e25-42ea-380a55104f0e@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=chrubis@suse.cz \
    --cc=guaneryu@gmail.com \
    --cc=jstancek@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=mszeredi@redhat.com \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).