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/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
