From: J. Bruce Fields <bfields@fieldses.org>
To: ltp@lists.linux.it
Subject: [LTP] utimensat EACCES vs. EPERM in 4.8+
Date: Tue, 17 Jan 2017 14:35:57 -0500 [thread overview]
Message-ID: <20170117193557.GA17332@fieldses.org> (raw)
In-Reply-To: <20170117044104.ktrtizpzhghqludn@thunk.org>
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.
WARNING: multiple messages have this Message-ID (diff)
From: bfields@fieldses.org (J. Bruce Fields)
To: Theodore Ts'o <tytso@mit.edu>
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 14:35:57 -0500 [thread overview]
Message-ID: <20170117193557.GA17332@fieldses.org> (raw)
In-Reply-To: <20170117044104.ktrtizpzhghqludn@thunk.org>
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.
next prev parent reply other threads:[~2017-01-17 19:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 15:46 [LTP] utimensat EACCES vs. EPERM in 4.8+ Jan Stancek
2017-01-16 15:46 ` Jan Stancek
2017-01-16 15:53 ` [LTP] " Miklos Szeredi
2017-01-16 15:53 ` Miklos Szeredi
2017-01-17 0:04 ` Michael Kerrisk (man-pages)
2017-01-17 0:04 ` [LTP] " Michael Kerrisk
[not found] ` <CAKgNAkjTkBMY0wrj3wsH39YF=bHp=8mbYrXkSPzn0X4ezfso1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-17 4:50 ` Carlos O'Donell
2017-01-17 4:50 ` Carlos O'Donell
2017-01-17 4:50 ` [LTP] " Carlos O'Donell
2017-01-17 7:51 ` Jan Stancek
2017-01-17 7:51 ` Jan Stancek
2017-01-17 7:51 ` [LTP] " Jan Stancek
2017-01-17 7:57 ` Cyril Hrubis
2017-01-17 7:57 ` [LTP] " Cyril Hrubis
[not found] ` <20170117075702.GB10417-2UyX9mZUyMU@public.gmane.org>
2017-01-17 9:39 ` Miklos Szeredi
2017-01-17 9:39 ` Miklos Szeredi
2017-01-17 9:39 ` [LTP] " Miklos Szeredi
[not found] ` <CAOssrKd32K-e5794m9KOjrMm_E3VZ7P-bvZW2P8UpGFTOgi8JQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-17 15:43 ` Cyril Hrubis
2017-01-17 15:43 ` Cyril Hrubis
2017-01-17 15:43 ` [LTP] " Cyril Hrubis
2017-01-18 8:23 ` Michael Kerrisk (man-pages)
2017-01-18 8:23 ` Michael Kerrisk (man-pages)
2017-01-18 8:23 ` [LTP] " Michael Kerrisk
[not found] ` <cb15e28d-8c5e-e3d7-441a-9165c4e57133-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-31 12:09 ` Cyril Hrubis
2017-01-31 12:09 ` Cyril Hrubis
2017-01-31 12:09 ` [LTP] " Cyril Hrubis
2017-01-17 4:41 ` Theodore Ts'o
2017-01-17 4:41 ` Theodore Ts'o
2017-01-17 19:35 ` J. Bruce Fields [this message]
2017-01-17 19:35 ` J. Bruce Fields
2017-01-17 21:04 ` [LTP] " Theodore Ts'o
2017-01-17 21:04 ` Theodore Ts'o
2017-01-18 8:17 ` [LTP] " Michael Kerrisk
2017-01-18 8:17 ` 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=20170117193557.GA17332@fieldses.org \
--to=bfields@fieldses.org \
--cc=ltp@lists.linux.it \
/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.