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

["Ethan Gardener" <eekee57@fastmail.fm>]

On Sat, Jun 6, 2020, at 10:13 PM, ori@eigenstate.org wrote:
> > 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.
> 
> This is a bit subtle, though -- if you want
> to check if *you* can traverse the directory,
> then simply checking for an execute bit isn't
> enough -- you need to check that you belong to
> a group that has the execute bit.
> 
> On a related note, execute permission seems
> to behave strangely in general. You can create
> a directory and list it:
> 
> 
> Even without execute permission it's listable.
> Makes sense.

sarcasm? i've been confused about search permission since my earliest linux use where i experimented with permissions to see what, exactly, they did. it made no sense then, even without plan 9 leaving permission checks up to the individual filesystems. (this would have been linux 2.0.0)

> 
> 	cpu% mkdir -p d/a/b
> 	cpu% touch d/x
> 	cpu% chmod -x d
> 	cpu% ls -ld d
> 	d-rw-r--r-- M 81 ori ori 0 Jun  5 07:53 d
> 	cpu% ls d
> 	d/a
> 	d/x
> 
> As expected, it can't be traversed:
> 
> 	cpu% ls d/x
> 	ls: d/x: 'd/x' does not exist
> 
> But, you can cd into it:
> 
> 	cpu% cd d
> 
> And list '.':
> 
> 	cpu% ls
> 	a
> 	x
> 	cpu% ls .
> 	a
> 	x
> 
> Can't traverse it to list subdirectories,
> though:
> 
> 	ls a
> 	ls: a: 'a' access permission denied
> 	cd a
> 	Can't cd a: 'a' access permission denied
> 	cpu% cd ..
> 	Can't cd ..: '..' access permission denied
> 
> So, cd'ing into a directory withut +x leads
> to an inescapabler trap.
> 
> Perhaps 'cd' should prevent entering that
> directory.

thanks for your analysis too, although you didn't say what filesystem you're using. i had to laugh at that trap; doesn't software get ridiculous sometimes? but it made me think, because charles said fossil doesn't handle the execute bit properly. perhaps once plan 9 went open source & had a public contrib, someone made just such a trap in contrib and fossil's permission handling was changed to stop it happening again. regardless of the cause, fossil just moved up another notch in my estimation because directory search restriction is so broken.

i just checked linux 2.6.30. (old vm i had handy.) it's much like you describe except there is no trap. cd is indeed prevented and if you're in the directory when "search" permission is revoked, you can't list it but you can `cd ..`.

"search" is exactly the wrong word for what this bit does, because if you don't have "search" permission, the one thing you can still do is look at the names... which lets you search them! it's more like "permission to open the display case and touch the things inside" or "permission to step over the museum's rope barriers".