utimensat EACCES vs. EPERM in 4.8+

utimensat EACCES vs. EPERM in 4.8+

[Jan Stancek]

Hi,

we seem to have a conflict between kernel and man pages.
>From utimensat man page:

EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
       *  the effective user ID of the caller does not match the owner of the
          file, the caller does not  have  write  access  to  the file, and the
          caller is not privileged (Linux: does not have either the CAP_FOWNER
          or the CAP_DAC_OVERRIDE capability); or,
       *  the file is marked immutable (see chattr(1)).

But following 2 commits gradually replaced EACCES with EPERM.

commit 337684a1746f93ae107e05d90977b070bb7e39d8
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Tue Aug 2 19:58:28 2016 +0800
    fs: return EPERM on immutable inode

commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Sep 16 12:44:20 2016 +0200
    vfs: move permission checking into notify_change() for utimes(NULL)

4.9 kernel and simple touch on immutable file gives me:
utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)

while an older kernel it gives me:
utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)

Do we need to update man page or fix kernel back to return EACCES?

Thanks,
Jan

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Jan Stancek]

Hi,

we seem to have a conflict between kernel and man pages.
From utimensat man page:

EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
       *  the effective user ID of the caller does not match the owner of the
          file, the caller does not  have  write  access  to  the file, and the
          caller is not privileged (Linux: does not have either the CAP_FOWNER
          or the CAP_DAC_OVERRIDE capability); or,
       *  the file is marked immutable (see chattr(1)).

But following 2 commits gradually replaced EACCES with EPERM.

commit 337684a1746f93ae107e05d90977b070bb7e39d8
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Tue Aug 2 19:58:28 2016 +0800
    fs: return EPERM on immutable inode

commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Sep 16 12:44:20 2016 +0200
    vfs: move permission checking into notify_change() for utimes(NULL)

4.9 kernel and simple touch on immutable file gives me:
utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)

while an older kernel it gives me:
utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)

Do we need to update man page or fix kernel back to return EACCES?

Thanks,
Jan

Re: utimensat EACCES vs. EPERM in 4.8+

[Miklos Szeredi]

On Mon, Jan 16, 2017 at 4:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
> Hi,
>
> we seem to have a conflict between kernel and man pages.
> From utimensat man page:
>
> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
>        *  the effective user ID of the caller does not match the owner of the
>           file, the caller does not  have  write  access  to  the file, and the
>           caller is not privileged (Linux: does not have either the CAP_FOWNER
>           or the CAP_DAC_OVERRIDE capability); or,
>        *  the file is marked immutable (see chattr(1)).
>
> But following 2 commits gradually replaced EACCES with EPERM.
>
> commit 337684a1746f93ae107e05d90977b070bb7e39d8
> Author: Eryu Guan <guaneryu@gmail.com>
> Date:   Tue Aug 2 19:58:28 2016 +0800
>     fs: return EPERM on immutable inode

I agree with Eryu that consistently returning EPERM for immutable is
better than sometimes returning EACCESS and sometimes EPERM.

So I think the man page should be fixed.

> commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b
> Author: Miklos Szeredi <mszeredi@redhat.com>
> Date:   Fri Sep 16 12:44:20 2016 +0200
>     vfs: move permission checking into notify_change() for utimes(NULL)

Actually this later commit didn't change the error value, it just
moved code around.

Thanks,
Miklos

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Miklos Szeredi]

On Mon, Jan 16, 2017 at 4:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
> Hi,
>
> we seem to have a conflict between kernel and man pages.
> From utimensat man page:
>
> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
>        *  the effective user ID of the caller does not match the owner of the
>           file, the caller does not  have  write  access  to  the file, and the
>           caller is not privileged (Linux: does not have either the CAP_FOWNER
>           or the CAP_DAC_OVERRIDE capability); or,
>        *  the file is marked immutable (see chattr(1)).
>
> But following 2 commits gradually replaced EACCES with EPERM.
>
> commit 337684a1746f93ae107e05d90977b070bb7e39d8
> Author: Eryu Guan <guaneryu@gmail.com>
> Date:   Tue Aug 2 19:58:28 2016 +0800
>     fs: return EPERM on immutable inode

I agree with Eryu that consistently returning EPERM for immutable is
better than sometimes returning EACCESS and sometimes EPERM.

So I think the man page should be fixed.

> commit f2b20f6ee842313a0d681dbbf7f87b70291a6a3b
> Author: Miklos Szeredi <mszeredi@redhat.com>
> Date:   Fri Sep 16 12:44:20 2016 +0200
>     vfs: move permission checking into notify_change() for utimes(NULL)

Actually this later commit didn't change the error value, it just
moved code around.

Thanks,
Miklos

Re: utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk (man-pages)]

[CC += linux-api + Dave Chinner]

On 17 January 2017 at 04:53, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Mon, Jan 16, 2017 at 4:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
>> Hi,
>>
>> we seem to have a conflict between kernel and man pages.

Jan, thanks for spotting this.

>> From utimensat man page:
>>
>> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
>>        *  the effective user ID of the caller does not match the owner of the
>>           file, the caller does not  have  write  access  to  the file, and the
>>           caller is not privileged (Linux: does not have either the CAP_FOWNER
>>           or the CAP_DAC_OVERRIDE capability); or,
>>        *  the file is marked immutable (see chattr(1)).
>>
>> But following 2 commits gradually replaced EACCES with EPERM.
>>
>> commit 337684a1746f93ae107e05d90977b070bb7e39d8
>> Author: Eryu Guan <guaneryu@gmail.com>
>> Date:   Tue Aug 2 19:58:28 2016 +0800
>>     fs: return EPERM on immutable inode
>
> I agree with Eryu that consistently returning EPERM for immutable is
> better than sometimes returning EACCESS and sometimes EPERM.

I'm not so sure about that. In Eryu's patch (which *really, really*
should have CCed linux-api@, and it would be kind if subsystem
maintainers reminded patch submitters about that), there was this
change:

[[
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -402,23 +402,23 @@ static inline int do_inode_permission(struct
inode *inode, int mask)
  * inode_permission().
  */
 int __inode_permission(struct inode *inode, int mask)
 {
        int retval;

        if (unlikely(mask & MAY_WRITE)) {
                /*
                 * Nobody gets write access to an immutable file.
                 */
                if (IS_IMMUTABLE(inode))
-                       return -EACCES;
+                       return -EPERM;

                /*
                 * Updating mtime will likely cause i_uid and i_gid to be
                 * written back improperly if their true value is unknown
                 * to the vfs.
                 */
                if (HAS_UNMAPPED_ID(inode))
                        return -EACCES;
        }

        retval = do_inode_permission(inode, mask);
]]

[1] The effects of that change are pretty wide ranging, affecting
open(2)/openat(2) (of an existing file for writing),
access(2)/faccessat(2) (W_OK), and [f]truncate(2). In addition, there
is the observed change (from another part of the patch) in
utimensat(2) (and friends). Those cases formerly gave EACCES for
immutable files, now they give EPERM.

[2] By contrast, the following always gave EPERM: fallocate(2),
setxattr(2), unlink(2), link(2) [in certain cases], chown(2),
chmod(2), and some per-filesystem cases of operations such as
truncate.

> So I think the man page should be fixed.

I agree that the inconsistency in the error return for immutable files
is unfortunate. But, consider the following:

* Although the set of calls in [1] is shorter, they (in particular,
  open(2)) are probably much more commonly used than
  the system calls in [2]. (That is, Eryu's statement "In most cases,
  EPERM is returned on immutable inode" that accompanied the
  kernel patch isn't correct.)
* For access(W_OK), we introduced a new error (EPERM) that
  previously never previously occurred. If there are applications
  that use access() and check specific error returns, they'll be
  confused. (I acknowledge there may be few such applications.)
* We changed the carefully documented behavior of utimensat(2)
  (and friends). [Read the man page!]
* EACCES is the typical error for "file not writable" (because of file
  permissions or other reasons such as immutability). It's long
  been the behavior for open(O_WRONLY/O_RDWR) on immutable
  files; now that has changed.
* Now various man pages need to document two different (kernel
  version dependent) errors for immutable files (for the syscalls in [1],
  above), and applications may need to deal with those two errors.

Summary of the above list: there's a nontrivial risk that something in
userspace got broken. (And just because we didn't hear about it yet
doesn't mean it didn't happen; sometimes these reports only arrive
many months or even years later.)

So, (1) I'm struggling to see the rationale for this change (I don't
think "consistency" is enough) and (2) if "consistency" is the
argument then (because the set of system calls in [1] are more
frequently used than those in [2]), there's a reasonable argument that
the change should have gone the other way: changing all IS_IMMUTABLE
cases to fail with EACCES.

Summary: I think there's an argument for reverting the kernel patch.

Cheers,

Michael

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

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk]

[CC += linux-api + Dave Chinner]

On 17 January 2017 at 04:53, Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Mon, Jan 16, 2017 at 4:46 PM, Jan Stancek <jstancek@redhat.com> wrote:
>> Hi,
>>
>> we seem to have a conflict between kernel and man pages.

Jan, thanks for spotting this.

>> From utimensat man page:
>>
>> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
>>        *  the effective user ID of the caller does not match the owner of the
>>           file, the caller does not  have  write  access  to  the file, and the
>>           caller is not privileged (Linux: does not have either the CAP_FOWNER
>>           or the CAP_DAC_OVERRIDE capability); or,
>>        *  the file is marked immutable (see chattr(1)).
>>
>> But following 2 commits gradually replaced EACCES with EPERM.
>>
>> commit 337684a1746f93ae107e05d90977b070bb7e39d8
>> Author: Eryu Guan <guaneryu@gmail.com>
>> Date:   Tue Aug 2 19:58:28 2016 +0800
>>     fs: return EPERM on immutable inode
>
> I agree with Eryu that consistently returning EPERM for immutable is
> better than sometimes returning EACCESS and sometimes EPERM.

I'm not so sure about that. In Eryu's patch (which *really, really*
should have CCed linux-api@, and it would be kind if subsystem
maintainers reminded patch submitters about that), there was this
change:

[[
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -402,23 +402,23 @@ static inline int do_inode_permission(struct
inode *inode, int mask)
  * inode_permission().
  */
 int __inode_permission(struct inode *inode, int mask)
 {
        int retval;

        if (unlikely(mask & MAY_WRITE)) {
                /*
                 * Nobody gets write access to an immutable file.
                 */
                if (IS_IMMUTABLE(inode))
-                       return -EACCES;
+                       return -EPERM;

                /*
                 * Updating mtime will likely cause i_uid and i_gid to be
                 * written back improperly if their true value is unknown
                 * to the vfs.
                 */
                if (HAS_UNMAPPED_ID(inode))
                        return -EACCES;
        }

        retval = do_inode_permission(inode, mask);
]]

[1] The effects of that change are pretty wide ranging, affecting
open(2)/openat(2) (of an existing file for writing),
access(2)/faccessat(2) (W_OK), and [f]truncate(2). In addition, there
is the observed change (from another part of the patch) in
utimensat(2) (and friends). Those cases formerly gave EACCES for
immutable files, now they give EPERM.

[2] By contrast, the following always gave EPERM: fallocate(2),
setxattr(2), unlink(2), link(2) [in certain cases], chown(2),
chmod(2), and some per-filesystem cases of operations such as
truncate.

> So I think the man page should be fixed.

I agree that the inconsistency in the error return for immutable files
is unfortunate. But, consider the following:

* Although the set of calls in [1] is shorter, they (in particular,
  open(2)) are probably much more commonly used than
  the system calls in [2]. (That is, Eryu's statement "In most cases,
  EPERM is returned on immutable inode" that accompanied the
  kernel patch isn't correct.)
* For access(W_OK), we introduced a new error (EPERM) that
  previously never previously occurred. If there are applications
  that use access() and check specific error returns, they'll be
  confused. (I acknowledge there may be few such applications.)
* We changed the carefully documented behavior of utimensat(2)
  (and friends). [Read the man page!]
* EACCES is the typical error for "file not writable" (because of file
  permissions or other reasons such as immutability). It's long
  been the behavior for open(O_WRONLY/O_RDWR) on immutable
  files; now that has changed.
* Now various man pages need to document two different (kernel
  version dependent) errors for immutable files (for the syscalls in [1],
  above), and applications may need to deal with those two errors.

Summary of the above list: there's a nontrivial risk that something in
userspace got broken. (And just because we didn't hear about it yet
doesn't mean it didn't happen; sometimes these reports only arrive
many months or even years later.)

So, (1) I'm struggling to see the rationale for this change (I don't
think "consistency" is enough) and (2) if "consistency" is the
argument then (because the set of system calls in [1] are more
frequently used than those in [2]), there's a reasonable argument that
the change should have gone the other way: changing all IS_IMMUTABLE
cases to fail with EACCES.

Summary: I think there's an argument for reverting the kernel patch.

Cheers,

Michael

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

Re: utimensat EACCES vs. EPERM in 4.8+

[Theodore Ts'o]

On Mon, Jan 16, 2017 at 04:46:45PM +0100, Jan Stancek wrote:
> 4.9 kernel and simple touch on immutable file gives me:
> utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)
> 
> while an older kernel it gives me:
> utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)
> 
> Do we need to update man page or fix kernel back to return EACCES?

Quoting from: http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html

   It appears that many programmers are unaware that there is a
   fundamental difference between the error codes EACCES (aka
   "Permission denied") and EPERM (aka "Operation not permitted"). In
   particular, a lot of code returns EPERM when they really mean
   EACCES:

   mist% killall sshd
   sshd(2244): Operation not permitted

   To clear this up: "Permission denied" means just that -- the
   process has insufficient privileges to perform the requested
   operation. Simply put, this means that "trying the same thing as
   root will work". For instance, messing around with files you do not
   have the appropriate permissions to (i.e. in the access(2) sense)
   will get you EACCES:

   mist% ls /root
   ls: cannot open directory /root: Permission denied

   On the other hand, "Operation not permitted" means the operation is
   systematically not permissible; in other words it would be unwise
   for the system to perform the requested operation -- regardless of
   access privileges (think "I can't let you do that,
   Dave."). Usually, this means that either the operation is not
   supported (e.g. chmodding a file residing on a FAT filesystem --
   FAT simply does not support permission bits, there is nothing
   anyone can do about that) or it would endanger the integrity of the
   system (e.g. creating additional hardlinks on a directory -- this
   would mess up the reference counting mechanism and result in "lost"
   disk space). Simply put, this means that "it cannot be done, not
   even as root".

   So next time you write code signalling errors with the E*
   constants, think hard before choosing: Do user privileges play a
   role in whether or not the error will occur? If yes, use EACCES. If
   no, use EPERM.

						- Ted

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Theodore Ts'o]

On Mon, Jan 16, 2017 at 04:46:45PM +0100, Jan Stancek wrote:
> 4.9 kernel and simple touch on immutable file gives me:
> utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)
> 
> while an older kernel it gives me:
> utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)
> 
> Do we need to update man page or fix kernel back to return EACCES?

Quoting from: http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html

   It appears that many programmers are unaware that there is a
   fundamental difference between the error codes EACCES (aka
   "Permission denied") and EPERM (aka "Operation not permitted"). In
   particular, a lot of code returns EPERM when they really mean
   EACCES:

   mist% killall sshd
   sshd(2244): Operation not permitted

   To clear this up: "Permission denied" means just that -- the
   process has insufficient privileges to perform the requested
   operation. Simply put, this means that "trying the same thing as
   root will work". For instance, messing around with files you do not
   have the appropriate permissions to (i.e. in the access(2) sense)
   will get you EACCES:

   mist% ls /root
   ls: cannot open directory /root: Permission denied

   On the other hand, "Operation not permitted" means the operation is
   systematically not permissible; in other words it would be unwise
   for the system to perform the requested operation -- regardless of
   access privileges (think "I can't let you do that,
   Dave."). Usually, this means that either the operation is not
   supported (e.g. chmodding a file residing on a FAT filesystem --
   FAT simply does not support permission bits, there is nothing
   anyone can do about that) or it would endanger the integrity of the
   system (e.g. creating additional hardlinks on a directory -- this
   would mess up the reference counting mechanism and result in "lost"
   disk space). Simply put, this means that "it cannot be done, not
   even as root".

   So next time you write code signalling errors with the E*
   constants, think hard before choosing: Do user privileges play a
   role in whether or not the error will occur? If yes, use EACCES. If
   no, use EPERM.

						- Ted

Re: utimensat EACCES vs. EPERM in 4.8+

[Carlos O'Donell]

On 01/16/2017 07:04 PM, Michael Kerrisk (man-pages) wrote:
> [CC += linux-api + Dave Chinner]

> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.

Completely agree.

Even if you go ahead with these changes, they really should go through
some kind of distro verification [1]. If I even contemplated such a change
in glibc I'd run it through 4-6 months of Fedora Rawhide builds just to
see what breaks before putting it out in a real release (and we do this
frequently for thread-related changes).

-- 
Cheers,
Carlos.

[1] "Usage of Fedora Rawhide" https://fedoraproject.org/wiki/Glibc

Re: utimensat EACCES vs. EPERM in 4.8+

[Carlos O'Donell]

On 01/16/2017 07:04 PM, Michael Kerrisk (man-pages) wrote:
> [CC += linux-api + Dave Chinner]

> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.

Completely agree.

Even if you go ahead with these changes, they really should go through
some kind of distro verification [1]. If I even contemplated such a change
in glibc I'd run it through 4-6 months of Fedora Rawhide builds just to
see what breaks before putting it out in a real release (and we do this
frequently for thread-related changes).

-- 
Cheers,
Carlos.

[1] "Usage of Fedora Rawhide" https://fedoraproject.org/wiki/Glibc

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Carlos O'Donell]

On 01/16/2017 07:04 PM, Michael Kerrisk (man-pages) wrote:
> [CC += linux-api + Dave Chinner]

> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.

Completely agree.

Even if you go ahead with these changes, they really should go through
some kind of distro verification [1]. If I even contemplated such a change
in glibc I'd run it through 4-6 months of Fedora Rawhide builds just to
see what breaks before putting it out in a real release (and we do this
frequently for thread-related changes).

-- 
Cheers,
Carlos.

[1] "Usage of Fedora Rawhide" https://fedoraproject.org/wiki/Glibc

Re: utimensat EACCES vs. EPERM in 4.8+

[Jan Stancek]

> >> we seem to have a conflict between kernel and man pages.
> 
> Jan, thanks for spotting this.

Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
with current documented behavior - few failures are expected on 4.8+.

Thanks for detailed analysis Michael!

> 
> >> From utimensat man page:
> >>
> >> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
> >>        *  the effective user ID of the caller does not match the owner of
> >>        the
> >>           file, the caller does not  have  write  access  to  the file,
> >>           and the
> >>           caller is not privileged (Linux: does not have either the
> >>           CAP_FOWNER
> >>           or the CAP_DAC_OVERRIDE capability); or,
> >>        *  the file is marked immutable (see chattr(1)).
> >>
> >> But following 2 commits gradually replaced EACCES with EPERM.
> >>
> >> commit 337684a1746f93ae107e05d90977b070bb7e39d8
> >> Author: Eryu Guan <guaneryu@gmail.com>
> >> Date:   Tue Aug 2 19:58:28 2016 +0800
> >>     fs: return EPERM on immutable inode
> >
> > I agree with Eryu that consistently returning EPERM for immutable is
> > better than sometimes returning EACCESS and sometimes EPERM.
> 
> I'm not so sure about that. In Eryu's patch (which *really, really*
> should have CCed linux-api@, and it would be kind if subsystem
> maintainers reminded patch submitters about that), there was this
> change:
> 
> [[
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -402,23 +402,23 @@ static inline int do_inode_permission(struct
> inode *inode, int mask)
>   * inode_permission().
>   */
>  int __inode_permission(struct inode *inode, int mask)
>  {
>         int retval;
> 
>         if (unlikely(mask & MAY_WRITE)) {
>                 /*
>                  * Nobody gets write access to an immutable file.
>                  */
>                 if (IS_IMMUTABLE(inode))
> -                       return -EACCES;
> +                       return -EPERM;
> 
>                 /*
>                  * Updating mtime will likely cause i_uid and i_gid to be
>                  * written back improperly if their true value is unknown
>                  * to the vfs.
>                  */
>                 if (HAS_UNMAPPED_ID(inode))
>                         return -EACCES;
>         }
> 
>         retval = do_inode_permission(inode, mask);
> ]]
> 
> [1] The effects of that change are pretty wide ranging, affecting
> open(2)/openat(2) (of an existing file for writing),
> access(2)/faccessat(2) (W_OK), and [f]truncate(2). In addition, there
> is the observed change (from another part of the patch) in
> utimensat(2) (and friends). Those cases formerly gave EACCES for
> immutable files, now they give EPERM.
> 
> [2] By contrast, the following always gave EPERM: fallocate(2),
> setxattr(2), unlink(2), link(2) [in certain cases], chown(2),
> chmod(2), and some per-filesystem cases of operations such as
> truncate.
> 
> > So I think the man page should be fixed.
> 
> I agree that the inconsistency in the error return for immutable files
> is unfortunate. But, consider the following:
> 
> * Although the set of calls in [1] is shorter, they (in particular,
>   open(2)) are probably much more commonly used than
>   the system calls in [2]. (That is, Eryu's statement "In most cases,
>   EPERM is returned on immutable inode" that accompanied the
>   kernel patch isn't correct.)
> * For access(W_OK), we introduced a new error (EPERM) that
>   previously never previously occurred. If there are applications
>   that use access() and check specific error returns, they'll be
>   confused. (I acknowledge there may be few such applications.)
> * We changed the carefully documented behavior of utimensat(2)
>   (and friends). [Read the man page!]
> * EACCES is the typical error for "file not writable" (because of file
>   permissions or other reasons such as immutability). It's long
>   been the behavior for open(O_WRONLY/O_RDWR) on immutable
>   files; now that has changed.
> * Now various man pages need to document two different (kernel
>   version dependent) errors for immutable files (for the syscalls in [1],
>   above), and applications may need to deal with those two errors.
> 
> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.
> 
> Cheers,
> 
> Michael
> 
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> 

Re: utimensat EACCES vs. EPERM in 4.8+

[Jan Stancek]

> >> we seem to have a conflict between kernel and man pages.
> 
> Jan, thanks for spotting this.

Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
with current documented behavior - few failures are expected on 4.8+.

Thanks for detailed analysis Michael!

> 
> >> From utimensat man page:
> >>
> >> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
> >>        *  the effective user ID of the caller does not match the owner of
> >>        the
> >>           file, the caller does not  have  write  access  to  the file,
> >>           and the
> >>           caller is not privileged (Linux: does not have either the
> >>           CAP_FOWNER
> >>           or the CAP_DAC_OVERRIDE capability); or,
> >>        *  the file is marked immutable (see chattr(1)).
> >>
> >> But following 2 commits gradually replaced EACCES with EPERM.
> >>
> >> commit 337684a1746f93ae107e05d90977b070bb7e39d8
> >> Author: Eryu Guan <guaneryu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date:   Tue Aug 2 19:58:28 2016 +0800
> >>     fs: return EPERM on immutable inode
> >
> > I agree with Eryu that consistently returning EPERM for immutable is
> > better than sometimes returning EACCESS and sometimes EPERM.
> 
> I'm not so sure about that. In Eryu's patch (which *really, really*
> should have CCed linux-api@, and it would be kind if subsystem
> maintainers reminded patch submitters about that), there was this
> change:
> 
> [[
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -402,23 +402,23 @@ static inline int do_inode_permission(struct
> inode *inode, int mask)
>   * inode_permission().
>   */
>  int __inode_permission(struct inode *inode, int mask)
>  {
>         int retval;
> 
>         if (unlikely(mask & MAY_WRITE)) {
>                 /*
>                  * Nobody gets write access to an immutable file.
>                  */
>                 if (IS_IMMUTABLE(inode))
> -                       return -EACCES;
> +                       return -EPERM;
> 
>                 /*
>                  * Updating mtime will likely cause i_uid and i_gid to be
>                  * written back improperly if their true value is unknown
>                  * to the vfs.
>                  */
>                 if (HAS_UNMAPPED_ID(inode))
>                         return -EACCES;
>         }
> 
>         retval = do_inode_permission(inode, mask);
> ]]
> 
> [1] The effects of that change are pretty wide ranging, affecting
> open(2)/openat(2) (of an existing file for writing),
> access(2)/faccessat(2) (W_OK), and [f]truncate(2). In addition, there
> is the observed change (from another part of the patch) in
> utimensat(2) (and friends). Those cases formerly gave EACCES for
> immutable files, now they give EPERM.
> 
> [2] By contrast, the following always gave EPERM: fallocate(2),
> setxattr(2), unlink(2), link(2) [in certain cases], chown(2),
> chmod(2), and some per-filesystem cases of operations such as
> truncate.
> 
> > So I think the man page should be fixed.
> 
> I agree that the inconsistency in the error return for immutable files
> is unfortunate. But, consider the following:
> 
> * Although the set of calls in [1] is shorter, they (in particular,
>   open(2)) are probably much more commonly used than
>   the system calls in [2]. (That is, Eryu's statement "In most cases,
>   EPERM is returned on immutable inode" that accompanied the
>   kernel patch isn't correct.)
> * For access(W_OK), we introduced a new error (EPERM) that
>   previously never previously occurred. If there are applications
>   that use access() and check specific error returns, they'll be
>   confused. (I acknowledge there may be few such applications.)
> * We changed the carefully documented behavior of utimensat(2)
>   (and friends). [Read the man page!]
> * EACCES is the typical error for "file not writable" (because of file
>   permissions or other reasons such as immutability). It's long
>   been the behavior for open(O_WRONLY/O_RDWR) on immutable
>   files; now that has changed.
> * Now various man pages need to document two different (kernel
>   version dependent) errors for immutable files (for the syscalls in [1],
>   above), and applications may need to deal with those two errors.
> 
> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.
> 
> Cheers,
> 
> Michael
> 
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> 

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Jan Stancek]

> >> we seem to have a conflict between kernel and man pages.
> 
> Jan, thanks for spotting this.

Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
with current documented behavior - few failures are expected on 4.8+.

Thanks for detailed analysis Michael!

> 
> >> From utimensat man page:
> >>
> >> EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either:
> >>        *  the effective user ID of the caller does not match the owner of
> >>        the
> >>           file, the caller does not  have  write  access  to  the file,
> >>           and the
> >>           caller is not privileged (Linux: does not have either the
> >>           CAP_FOWNER
> >>           or the CAP_DAC_OVERRIDE capability); or,
> >>        *  the file is marked immutable (see chattr(1)).
> >>
> >> But following 2 commits gradually replaced EACCES with EPERM.
> >>
> >> commit 337684a1746f93ae107e05d90977b070bb7e39d8
> >> Author: Eryu Guan <guaneryu@gmail.com>
> >> Date:   Tue Aug 2 19:58:28 2016 +0800
> >>     fs: return EPERM on immutable inode
> >
> > I agree with Eryu that consistently returning EPERM for immutable is
> > better than sometimes returning EACCESS and sometimes EPERM.
> 
> I'm not so sure about that. In Eryu's patch (which *really, really*
> should have CCed linux-api@, and it would be kind if subsystem
> maintainers reminded patch submitters about that), there was this
> change:
> 
> [[
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -402,23 +402,23 @@ static inline int do_inode_permission(struct
> inode *inode, int mask)
>   * inode_permission().
>   */
>  int __inode_permission(struct inode *inode, int mask)
>  {
>         int retval;
> 
>         if (unlikely(mask & MAY_WRITE)) {
>                 /*
>                  * Nobody gets write access to an immutable file.
>                  */
>                 if (IS_IMMUTABLE(inode))
> -                       return -EACCES;
> +                       return -EPERM;
> 
>                 /*
>                  * Updating mtime will likely cause i_uid and i_gid to be
>                  * written back improperly if their true value is unknown
>                  * to the vfs.
>                  */
>                 if (HAS_UNMAPPED_ID(inode))
>                         return -EACCES;
>         }
> 
>         retval = do_inode_permission(inode, mask);
> ]]
> 
> [1] The effects of that change are pretty wide ranging, affecting
> open(2)/openat(2) (of an existing file for writing),
> access(2)/faccessat(2) (W_OK), and [f]truncate(2). In addition, there
> is the observed change (from another part of the patch) in
> utimensat(2) (and friends). Those cases formerly gave EACCES for
> immutable files, now they give EPERM.
> 
> [2] By contrast, the following always gave EPERM: fallocate(2),
> setxattr(2), unlink(2), link(2) [in certain cases], chown(2),
> chmod(2), and some per-filesystem cases of operations such as
> truncate.
> 
> > So I think the man page should be fixed.
> 
> I agree that the inconsistency in the error return for immutable files
> is unfortunate. But, consider the following:
> 
> * Although the set of calls in [1] is shorter, they (in particular,
>   open(2)) are probably much more commonly used than
>   the system calls in [2]. (That is, Eryu's statement "In most cases,
>   EPERM is returned on immutable inode" that accompanied the
>   kernel patch isn't correct.)
> * For access(W_OK), we introduced a new error (EPERM) that
>   previously never previously occurred. If there are applications
>   that use access() and check specific error returns, they'll be
>   confused. (I acknowledge there may be few such applications.)
> * We changed the carefully documented behavior of utimensat(2)
>   (and friends). [Read the man page!]
> * EACCES is the typical error for "file not writable" (because of file
>   permissions or other reasons such as immutability). It's long
>   been the behavior for open(O_WRONLY/O_RDWR) on immutable
>   files; now that has changed.
> * Now various man pages need to document two different (kernel
>   version dependent) errors for immutable files (for the syscalls in [1],
>   above), and applications may need to deal with those two errors.
> 
> Summary of the above list: there's a nontrivial risk that something in
> userspace got broken. (And just because we didn't hear about it yet
> doesn't mean it didn't happen; sometimes these reports only arrive
> many months or even years later.)
> 
> So, (1) I'm struggling to see the rationale for this change (I don't
> think "consistency" is enough) and (2) if "consistency" is the
> argument then (because the set of system calls in [1] are more
> frequently used than those in [2]), there's a reasonable argument that
> the change should have gone the other way: changing all IS_IMMUTABLE
> cases to fail with EACCES.
> 
> Summary: I think there's an argument for reverting the kernel patch.
> 
> Cheers,
> 
> Michael
> 
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> 

Re: utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> > Jan, thanks for spotting this.
> 
> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
> with current documented behavior - few failures are expected on 4.8+.

Actually credit goes to SUSE QAM that caught the change on kernel
update :-).

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> > Jan, thanks for spotting this.
> 
> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
> with current documented behavior - few failures are expected on 4.8+.

Actually credit goes to SUSE QAM that caught the change on kernel
update :-).

-- 
Cyril Hrubis
chrubis@suse.cz

Re: utimensat EACCES vs. EPERM in 4.8+

[Miklos Szeredi]

On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
>> > Jan, thanks for spotting this.
>>
>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>> with current documented behavior - few failures are expected on 4.8+.
>
> Actually credit goes to SUSE QAM that caught the change on kernel
> update :-).

And while this makes for a nice discussion, it is almost completely
irrelevant in real life, since the only thing broken by this change
will be test suites (in other words immutable files are rare as hen's
teeth).

If you find that this change actually breaks something other than a
test suite, then yes, please lets revert it.  Otherwise there's not
much point (distros can revert it for themselves if they want be
paranoid).

Thanks,
Miklos

Re: utimensat EACCES vs. EPERM in 4.8+

[Miklos Szeredi]

On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
> Hi!
>> > Jan, thanks for spotting this.
>>
>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>> with current documented behavior - few failures are expected on 4.8+.
>
> Actually credit goes to SUSE QAM that caught the change on kernel
> update :-).

And while this makes for a nice discussion, it is almost completely
irrelevant in real life, since the only thing broken by this change
will be test suites (in other words immutable files are rare as hen's
teeth).

If you find that this change actually breaks something other than a
test suite, then yes, please lets revert it.  Otherwise there's not
much point (distros can revert it for themselves if they want be
paranoid).

Thanks,
Miklos

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Miklos Szeredi]

On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
>> > Jan, thanks for spotting this.
>>
>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>> with current documented behavior - few failures are expected on 4.8+.
>
> Actually credit goes to SUSE QAM that caught the change on kernel
> update :-).

And while this makes for a nice discussion, it is almost completely
irrelevant in real life, since the only thing broken by this change
will be test suites (in other words immutable files are rare as hen's
teeth).

If you find that this change actually breaks something other than a
test suite, then yes, please lets revert it.  Otherwise there's not
much point (distros can revert it for themselves if they want be
paranoid).

Thanks,
Miklos

Re: utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> > Actually credit goes to SUSE QAM that caught the change on kernel
> > update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

We do have documentation and code out of sync so this is a valid bug
regardless of which one of them ends up fixed in the end...

-- 
Cyril Hrubis
chrubis@suse.cz

Re: utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> > Actually credit goes to SUSE QAM that caught the change on kernel
> > update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

We do have documentation and code out of sync so this is a valid bug
regardless of which one of them ends up fixed in the end...

-- 
Cyril Hrubis
chrubis-AlSwsSmVLrQ@public.gmane.org

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> > Actually credit goes to SUSE QAM that caught the change on kernel
> > update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

We do have documentation and code out of sync so this is a valid bug
regardless of which one of them ends up fixed in the end...

-- 
Cyril Hrubis
chrubis@suse.cz

Re: utimensat EACCES vs. EPERM in 4.8+

[J. Bruce Fields]

On Mon, Jan 16, 2017 at 11:41:05PM -0500, Theodore Ts'o wrote:
> On Mon, Jan 16, 2017 at 04:46:45PM +0100, Jan Stancek wrote:
> > 4.9 kernel and simple touch on immutable file gives me:
> > utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)
> > 
> > while an older kernel it gives me:
> > utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)
> > 
> > Do we need to update man page or fix kernel back to return EACCES?
> 
> Quoting from: http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html
>    It appears that many programmers are unaware that there is a
>    fundamental difference between the error codes EACCES (aka
>    "Permission denied") and EPERM (aka "Operation not permitted"). In
>    particular, a lot of code returns EPERM when they really mean
>    EACCES:
> 
>    mist% killall sshd
>    sshd(2244): Operation not permitted

That's posix, not just linux.

>    To clear this up: "Permission denied" means just that -- the
>    process has insufficient privileges to perform the requested
>    operation. Simply put, this means that "trying the same thing as
>    root will work".

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

--b.

[LTP] utimensat EACCES vs. EPERM in 4.8+

[J. Bruce Fields]

On Mon, Jan 16, 2017 at 11:41:05PM -0500, Theodore Ts'o wrote:
> On Mon, Jan 16, 2017 at 04:46:45PM +0100, Jan Stancek wrote:
> > 4.9 kernel and simple touch on immutable file gives me:
> > utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EPERM (Operation not permitted)
> > 
> > while an older kernel it gives me:
> > utimensat(AT_FDCWD, "afile", NULL, 0)   = -1 EACCES (Permission denied)
> > 
> > Do we need to update man page or fix kernel back to return EACCES?
> 
> Quoting from: http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html
>    It appears that many programmers are unaware that there is a
>    fundamental difference between the error codes EACCES (aka
>    "Permission denied") and EPERM (aka "Operation not permitted"). In
>    particular, a lot of code returns EPERM when they really mean
>    EACCES:
> 
>    mist% killall sshd
>    sshd(2244): Operation not permitted

That's posix, not just linux.

>    To clear this up: "Permission denied" means just that -- the
>    process has insufficient privileges to perform the requested
>    operation. Simply put, this means that "trying the same thing as
>    root will work".

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

--b.

Re: utimensat EACCES vs. EPERM in 4.8+

[Theodore Ts'o]

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

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Theodore Ts'o]

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

Re: utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk (man-pages)]

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/

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk]

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/

Re: utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk (man-pages)]

Hi Miklos,

On 01/17/2017 10:39 PM, Miklos Szeredi wrote:
> On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
>> Hi!
>>>> Jan, thanks for spotting this.
>>>
>>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>>> with current documented behavior - few failures are expected on 4.8+.
>>
>> Actually credit goes to SUSE QAM that caught the change on kernel
>> update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

While I agree that the chances of breakage may be quite small (though
I certainly won't be so bold as to assert that only test suites
will get broken), your comment misses the important metapoint:
changes like this should not just be getting waved through the gate
without some analysis along the lines of what I did. "Consistency"
and an (incorrect) assertion that "In most cases, EPERM is returned
on immutable inode" just don't cut it, when it comes to making
changes of this sort.

> If you find that this change actually breaks something other than a
> test suite, then yes, please lets revert it.  

No. That is not a strategy. I already said it, but I'll say it again:
sometimes these reports only arrive many months or even years later.
And then we can end up with fiascoes such as F_SETOWN/F_SETOWN_EX.
(Essentially: F_SETOWN got subtly changed, and by the time people
realized the breakage had occurred it was *years* late. Too late to
revert... So, then we got F_SETOWN_EX to allow us what F_SETOWN
used to do. See fcntl(2).)

> Otherwise there's not
> much point (distros can revert it for themselves if they want be
> paranoid).

Also not a strategy; distros don't want to carry such junk
patches.

All of this said, I still don't know whether reverting the patch
is warranted...

Cheers,

Michael

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

Re: utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk (man-pages)]

Hi Miklos,

On 01/17/2017 10:39 PM, Miklos Szeredi wrote:
> On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org> wrote:
>> Hi!
>>>> Jan, thanks for spotting this.
>>>
>>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>>> with current documented behavior - few failures are expected on 4.8+.
>>
>> Actually credit goes to SUSE QAM that caught the change on kernel
>> update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

While I agree that the chances of breakage may be quite small (though
I certainly won't be so bold as to assert that only test suites
will get broken), your comment misses the important metapoint:
changes like this should not just be getting waved through the gate
without some analysis along the lines of what I did. "Consistency"
and an (incorrect) assertion that "In most cases, EPERM is returned
on immutable inode" just don't cut it, when it comes to making
changes of this sort.

> If you find that this change actually breaks something other than a
> test suite, then yes, please lets revert it.  

No. That is not a strategy. I already said it, but I'll say it again:
sometimes these reports only arrive many months or even years later.
And then we can end up with fiascoes such as F_SETOWN/F_SETOWN_EX.
(Essentially: F_SETOWN got subtly changed, and by the time people
realized the breakage had occurred it was *years* late. Too late to
revert... So, then we got F_SETOWN_EX to allow us what F_SETOWN
used to do. See fcntl(2).)

> Otherwise there's not
> much point (distros can revert it for themselves if they want be
> paranoid).

Also not a strategy; distros don't want to carry such junk
patches.

All of this said, I still don't know whether reverting the patch
is warranted...

Cheers,

Michael

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

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Michael Kerrisk]

Hi Miklos,

On 01/17/2017 10:39 PM, Miklos Szeredi wrote:
> On Tue, Jan 17, 2017 at 8:57 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
>> Hi!
>>>> Jan, thanks for spotting this.
>>>
>>> Credit goes to Cyril. As for LTP-20170116 (released yesterday) we went
>>> with current documented behavior - few failures are expected on 4.8+.
>>
>> Actually credit goes to SUSE QAM that caught the change on kernel
>> update :-).
> 
> And while this makes for a nice discussion, it is almost completely
> irrelevant in real life, since the only thing broken by this change
> will be test suites (in other words immutable files are rare as hen's
> teeth).

While I agree that the chances of breakage may be quite small (though
I certainly won't be so bold as to assert that only test suites
will get broken), your comment misses the important metapoint:
changes like this should not just be getting waved through the gate
without some analysis along the lines of what I did. "Consistency"
and an (incorrect) assertion that "In most cases, EPERM is returned
on immutable inode" just don't cut it, when it comes to making
changes of this sort.

> If you find that this change actually breaks something other than a
> test suite, then yes, please lets revert it.  

No. That is not a strategy. I already said it, but I'll say it again:
sometimes these reports only arrive many months or even years later.
And then we can end up with fiascoes such as F_SETOWN/F_SETOWN_EX.
(Essentially: F_SETOWN got subtly changed, and by the time people
realized the breakage had occurred it was *years* late. Too late to
revert... So, then we got F_SETOWN_EX to allow us what F_SETOWN
used to do. See fcntl(2).)

> Otherwise there's not
> much point (distros can revert it for themselves if they want be
> paranoid).

Also not a strategy; distros don't want to carry such junk
patches.

All of this said, I still don't know whether reverting the patch
is warranted...

Cheers,

Michael

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

Re: utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> All of this said, I still don't know whether reverting the patch
> is warranted...

Ping.

What shall we do with the failing testcase?

I guess that since the discussion withered the patch will stay in kernel
as it is and the manual needs to be updated...

-- 
Cyril Hrubis
chrubis@suse.cz

Re: utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> All of this said, I still don't know whether reverting the patch
> is warranted...

Ping.

What shall we do with the failing testcase?

I guess that since the discussion withered the patch will stay in kernel
as it is and the manual needs to be updated...

-- 
Cyril Hrubis
chrubis-AlSwsSmVLrQ@public.gmane.org

[LTP] utimensat EACCES vs. EPERM in 4.8+

[Cyril Hrubis]

Hi!
> All of this said, I still don't know whether reverting the patch
> is warranted...

Ping.

What shall we do with the failing testcase?

I guess that since the discussion withered the patch will stay in kernel
as it is and the manual needs to be updated...

-- 
Cyril Hrubis
chrubis@suse.cz