Author: Matthew Byng-Maddick Date: To: Stephen Bennett CC: users, Roger Light, baechler Subject: Re: [bitfolk] File and folder permissions for static web pages
On Tue, Mar 12, 2013 at 05:48:08PM +0000, Stephen Bennett wrote: > On Tue, Mar 12, 2013 at 10:40:12AM -0700, Matthew Byng-Maddick wrote:
> > Yeah - fair point, in which case POSIX/SUS3 is using misleading terminology,
> > which'll make newbies get it wrong! :-( Search, to me, implies what the
> > directory read permission is for (ie. what're the contents of the directory)
>
> Search is a different permission from read. Search allows you to test
> for the existence of a file within that directory; read allows you to
> retrieve the full list. Running stat() on /foo/bar requires search
> permission on /foo, but not read permission. The terminology is only
> misleading if you don't appreciate that distinction.
What!?
What system do you use where the contents of the directory inode, when
read(2) is called, do not equal its actual contents. The whole point is
that you need the execute to enter, search or explore the directory.
stat(2) in the case you describe is an operation on the file inode, and
so just being able to tell that the inode is in the directory is not
enough, because you can't enter the directory to operate on that inode.
What you're seeing is that namei() (or whatever it's called in modern
linux, the function that resolves inode numbers from paths) cannot enter
that directory as that user because there is no execute permission. That
means that you get EACCES back, and so that's what you get back from stat().
It's specious to talk about the "existence of a file" - because you can
see whether the file exists by looking at the contents of the directory,
which you can see. You just can't see anything (metadata or data) about
that file, because you can't enter the directory to go and look,
WHATEVER the permissions on the file happen to be.
