leo@marco.UUCP (Matthias Pfaller) (08/10/90)
Yesterday I noticed, that even root does not have search permissions on directories with mode d---------. Today I tried it on a real unix box and here it is allowd. Bug or feature? Matthias Pfaller (leo@marco.de)
jms@cs.vu.nl (Jan-Mark) (08/10/90)
In an article, leo@marco.UUCP (Matthias Pfaller) writes: > Yesterday I noticed, that even root does not have search permissions > on directories with mode d---------. Today I tried it on a real unix > box and here it is allowd. Bug or feature? This should be a bug. The origin isn't hard to gess. Since even root needs at least one x-bit to be able to execute a file. And the x-bit hapens to be the search permission-bit for directories. From fs/protect.c: # # /* If none of the X bits are on, not even the super-user can execute it. */ # xmask = (X_BIT << 6) | (X_BIT << 3) | X_BIT; /* all 3 X bits */ # if ( (access_desired & X_BIT) && (bits & xmask) == 0) r = EACCES; # It's obivouse some check on the d-bit is needed as wel. -- (:> jms (_) ========""======
abc@adm.BRL.MIL (Brinton Cooper) (08/10/90)
In article <454@alice.marco.UUCP> leo@marco.UUCP (Matthias Pfaller) writes: >Yesterday I noticed, that even root does not have search permissions >on directories with mode d---------. Today I tried it on a real unix >box and here it is allowd. Bug or feature? Ditto here. Root can read such a directory on a Sun running Berkeley 4.2 Unix. _Brint -- _Brinton Cooper BRL - Where "Research" is our Middle Name.
brucee@runxtsa.runx.oz.au (Bruce Evans) (08/13/90)
In article <454@alice.marco.UUCP> you write: >Yesterday I noticed, that even root does not have search permissions >on directories with mode d---------. Today I tried it on a real unix Perhaps the test in FS is backwards. Let d be such a directory and f a file in it. Then ls d works, while ls -l d and ls d/f fail. -- Bruce Evans Internet: brucee@runxtsa.runx.oz.au UUCP: uunet!runxtsa.runx.oz.au!brucee (My other address (evans@ditsyda.oz.au) no longer works)
brucee@runxtsa.runx.oz.au (Bruce Evans) (08/14/90)
In article <7282@star.cs.vu.nl> jms@cs.vu.nl (Jan-Mark Wams) writes: >In an article, leo@marco.UUCP (Matthias Pfaller) writes: > >> Yesterday I noticed, that even root does not have search permissions >> on directories with mode d---------. Today I tried it on a real unix >> box and here it is allowd. Bug or feature? > > This should be a bug. The origin isn't hard to gess. Since > even root needs at least one x-bit to be able to execute a > file. And the x-bit hapens to be the search permission-bit > for directories. > >From fs/protect.c: > ># /* If none of the X bits are on, not even the super-user can execute it. */ ># xmask = (X_BIT << 6) | (X_BIT << 3) | X_BIT; /* all 3 X bits */ ># if ( (access_desired & X_BIT) && (bits & xmask) == 0) r = EACCES; I think the fix is simply to discard these lines (and the declaration of the `variable' xmask) . The function allowed() in mm/utility.c already checks the X bits with their `executable' meaning. I think FS doesn't know about executable files and only uses the X bits as directory-search permissions, apart from this bug. What about another permissions bug, that executing a file requires read permission? At least 2 fixes have been posted, one last year and one the year before or earlier, but the bug is still in 1.5. The earlier fix at least was a kludge. I think that the right way to fix it is for MM to always have superuser permissions, so that it can open and read all files (even if it wants to execute them ;-). To execute a file, MM need only check for execute permission, and already does so. Currently, MM switches to the user's effective uid as part of the tell_fs(CHDIR, ...) for exec, so it loses its read permission on some executable files. The only other place MM does a tell_fs(CHDIR, ...) is for core dumps. If having the user's effective uid is necessary or convenient for this, it is much better to set it explicitly. -- Bruce Evans Internet: brucee@runxtsa.runx.oz.au UUCP: uunet!runxtsa.runx.oz.au!brucee (My other address (evans@ditsyda.oz.au) no longer works)