All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: 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, mtk.manpages@gmail.com
Subject: Re: utimensat EACCES vs. EPERM in 4.8+
Date: Tue, 17 Jan 2017 16:04:03 -0500	[thread overview]
Message-ID: <20170117210403.spl6fpzegfmir6cy@thunk.org> (raw)
In-Reply-To: <20170117193557.GA17332@fieldses.org>

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).

Yeah, the blog entry is over-generalizing a bit too much.  But if you
take a look at the entry for unlink:

[EACCES]
   Search permission is denied for a component of the path prefix, or
   write permission is denied on the directory containing the
   directory entry to be removed
[EPERM]
   The file named by path is a directory, and either the calling
   process does not have appropriate privileges, or the implementation
   prohibits using unlink() on directories.
[EPERM] or [EACCES]
   The S_ISVTX flag is set on the directory containing the file
   referred to by the path argument and the process does not satisfy
   the criteria specified in XBD Directory Protection.

The second entry, for EPERM, is an example of the "I'm sorry, Dave, I
won't let you do that".  (Early AT&T Unices allowed you to call unlink
on a directory if you were root, even if it resulted in corrupting the
file system.  BSD changed that to be "F*ck that, I don't care if
you're root, I'm not going to let you do that.

In generally there are a lot of cases where people will return EPERM
when technically EACCES is a much better closer match what they should
use.  But the last one shows that there's quite a lot of confusion
even with systems that are allowed to call themselves Unix-complaint
by virtue of their parantage of their code base (as opposed to
compliance to a standards document).

						- Ted

WARNING: multiple messages have this Message-ID (diff)
From: Theodore Ts'o <tytso@mit.edu>
To: ltp@lists.linux.it
Subject: [LTP] utimensat EACCES vs. EPERM in 4.8+
Date: Tue, 17 Jan 2017 16:04:03 -0500	[thread overview]
Message-ID: <20170117210403.spl6fpzegfmir6cy@thunk.org> (raw)
In-Reply-To: <20170117193557.GA17332@fieldses.org>

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).

Yeah, the blog entry is over-generalizing a bit too much.  But if you
take a look at the entry for unlink:

[EACCES]
   Search permission is denied for a component of the path prefix, or
   write permission is denied on the directory containing the
   directory entry to be removed
[EPERM]
   The file named by path is a directory, and either the calling
   process does not have appropriate privileges, or the implementation
   prohibits using unlink() on directories.
[EPERM] or [EACCES]
   The S_ISVTX flag is set on the directory containing the file
   referred to by the path argument and the process does not satisfy
   the criteria specified in XBD Directory Protection.

The second entry, for EPERM, is an example of the "I'm sorry, Dave, I
won't let you do that".  (Early AT&T Unices allowed you to call unlink
on a directory if you were root, even if it resulted in corrupting the
file system.  BSD changed that to be "F*ck that, I don't care if
you're root, I'm not going to let you do that.

In generally there are a lot of cases where people will return EPERM
when technically EACCES is a much better closer match what they should
use.  But the last one shows that there's quite a lot of confusion
even with systems that are allowed to call themselves Unix-complaint
by virtue of their parantage of their code base (as opposed to
compliance to a standards document).

						- Ted

  reply	other threads:[~2017-01-17 21:04 UTC|newest]

Thread overview: 34+ 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:46 ` [LTP] " Jan Stancek
2017-01-16 15:53 ` Miklos Szeredi
2017-01-16 15:53   ` [LTP] " Miklos Szeredi
2017-01-17  0:04   ` Michael Kerrisk (man-pages)
2017-01-17  0:04     ` [LTP] " Michael Kerrisk
2017-01-17  4:50     ` Carlos O'Donell
2017-01-17  4:50       ` [LTP] " Carlos O'Donell
2017-01-17  4:50       ` Carlos O'Donell
2017-01-17  7:51     ` Jan Stancek
2017-01-17  7:51       ` [LTP] " Jan Stancek
2017-01-17  7:51       ` Jan Stancek
2017-01-17  7:57       ` Cyril Hrubis
2017-01-17  7:57         ` [LTP] " Cyril Hrubis
2017-01-17  9:39         ` Miklos Szeredi
2017-01-17  9:39           ` [LTP] " Miklos Szeredi
2017-01-17  9:39           ` Miklos Szeredi
2017-01-17 15:43           ` Cyril Hrubis
2017-01-17 15:43             ` [LTP] " Cyril Hrubis
2017-01-17 15:43             ` Cyril Hrubis
2017-01-18  8:23           ` Michael Kerrisk (man-pages)
2017-01-18  8:23             ` [LTP] " Michael Kerrisk
2017-01-18  8:23             ` Michael Kerrisk (man-pages)
2017-01-31 12:09             ` Cyril Hrubis
2017-01-31 12:09               ` [LTP] " Cyril Hrubis
2017-01-31 12:09               ` Cyril Hrubis
2017-01-17  4:41 ` Theodore Ts'o
2017-01-17  4:41   ` [LTP] " Theodore Ts'o
2017-01-17 19:35   ` J. Bruce Fields
2017-01-17 19:35     ` [LTP] " J. Bruce Fields
2017-01-17 21:04     ` Theodore Ts'o [this message]
2017-01-17 21:04       ` Theodore Ts'o
2017-01-18  8:17       ` Michael Kerrisk (man-pages)
2017-01-18  8:17         ` [LTP] " Michael Kerrisk

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=20170117210403.spl6fpzegfmir6cy@thunk.org \
    --to=tytso@mit.edu \
    --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=mtk.manpages@gmail.com \
    --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 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.