Re: [9fans] `test -x` returns wrong results for directories

[Charles Forsyth <charles.forsyth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

execute permission on files, meaning here non-directories, is a special
variant of read. a file with mode 0111 can be opened with OEXEC and read(2)
will work as well as exec(2),
but can't be opened with OREAD, because it's not got any of 0444 set. bits
0111 distinguish a file with contents that are intended to be executed once
read from files with only 0444 that do not contain executable content.
you wouldn't want every readable file to be executable (especially if
you've used systems that didn't have that distinction).
on the other hand, in a distributed file system, the client needs the
contents of the file to run it (whether code or #!script) so it needs to be
able to read files with just OEXEC.
I suppose the rule could have been that it would need mode 5 (r+x) to make
clear that the file was also readable, but it isn't.

that OEXEC allows reading isn't true for a directory because exec means
"search", so if it's mode 0111 (say) you can chdir into it but not read the
names within it.
if you know a name of a file in that directory, though, you can still open
that. that's entirely enforced by the server.

as the bug in access(2) suggests, only the server knows whether access
should be granted, and the open call gets it to do that,
but it doesn't work for OEXEC for directories as others have noted. perhaps
stat+chdir is the most accurate test, since you need x (search) permission
to walk(5) into a directory,
but the caller won't thank you for the chdir (and there's no easy or
certain way back), and ... that restriction isn't enforced by fossil or
ramfs. (ramfs wrongly allows you to read a directory that's mode 0.)

probably the best thing is just to ignore the owner/group/other
distinction, and if the open(...OEXEC) fails, dirstat it, and if it's a
directory with any of 0111 set, it's fine (a little better than now).



On Sat, Jun 6, 2020 at 7:38 AM Ethan Gardener <eekee57@fastmail.fm> wrote:

> On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote:
> > Looks to me like access(2) is not doing the right thing for directory
> > execute (=search) permission.
>
> thanks for the tip. access is a very simple function. it doesn't do the
> right thing, but there's a reason:
>
>      BUGS
>           Since file permissions are checked by the server and group
>           information is not known to the client, access must open the
>           file to check permissions.  (It calls stat(2) to check sim-
>           ple existence.)
>
> it's open() which is failing. i suppose it should.
>
> if the open fails, maybe access should stat the file, and if it's a
> directory, try dirread(2). or maybe just opening it for reading will work.
> i don't know, i'm new to this bit of plan 9 & i haven't slept.
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M6c82b233d9b0cabf21ca7512
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 3840 bytes --]