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 <[email protected]> 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-M873b037de0ec96e4b493d3d7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
