mdm@cocktrice.uucp (Mike Mitchell) (12/21/90)
After having installed Bruce Evan's patches for 386/Minix, I have noticed one problem. I think that this may be a generic problem with either fs or mm, however I have not yet found the offending code. I have been attempting to install uupc; I desired to have all executables in /bin and /usr/bin protected in such a manner that only the execute bit is on. I changed the mode of all files to reflect the fact that group and world read/write bits had been removed. login cannot exec /bin/sh when it has been changed to 511; this makes it impossible for a user account to be created and used. When I changed the protections of /bin/sh to 555, login was able to exec the shell and allow the user to login. When the login had succeeded in execing a copy of /bin/sh the next problem to crop up was 'ls: cannot execute'. By changing the mode of ls from 511 to 555, it began to work. Having files readable by group and world is defeats the purpose of having the execute bit the only one set. I would really like to keep user accounts from being able to access the binaries. What am I doing incorrectly? Is there a patch to fix this? Thank you very much for your time and effort. -- Mike Mitchell Mail: ...!uunet!dmk3b1!cocktrice!mdm 2020 Calle Lorca #43 Phone: (505) 471-7639 H Santa Fe, New Mexico 87505 (505) 473-4482 W
agm@stl.stc.co.uk (Andrew G. Minter) (12/21/90)
>login cannot exec /bin/sh when it has been changed to 511;
I've seen this problem before, and I believe the it is in the MM. If my
memory serves me correctly the MM, when executing an exec, somehow changes
it's effective user id to that of the user before calling the FS. If it
didn't do this, the FS would think the request was coming from a process
running as root and would treat permissions of files and directories
accordingly. Since the MM has to read the file (using read calls) to load
it in, it needs to have read permission.
The problem is by no means insoluble, but it will take more than a simple
patch to fix.
Perhaps this will be fixed in AST's 1.6, drool, drool.
Andrewarcher%segin4.segin.fr@relay.prime.com (Vincent Archer) (12/22/90)
In a message of 21 Dec 90 00:30:30 GMT, Mike Mitchell <mdm%cocktrice.UUCP> says > After having installed Bruce Evan's patches for 386/Minix, I have noticed > one problem. I think that this may be a generic problem with either fs or > mm, however I have not yet found the offending code. > > [...problem description about programs needing r-- bit to execute...] > > What am I doing incorrectly? Is there a patch to fix this? Thank you very > much for your time and effort. The actual problem resides in BOTH FS & MM. Namely, once MM does something on the behalf of some user process (like an exec() call), it calls FS to set up the same current home (and root - on my system) directory as the caller, then begins working. In addition, the same code also copies the user id, because this function is called when MM dumps core (and core dumps need to have the process user id rather than root). What this means is that MM temporarily drops its root privileges, and, when trying to open the executable file, fails since r-- is not allowed... I don't know if that bug is adressed to in 1.6? If it is not, once 1.6 reach the world, I will try to add a patch that separates home/root & userid/groupid settings, so that exec WILL work as expected... Vincent Archer Email: archer%segin4.segin.fr@relay.prime.com "The term `panic' is, by definition, frightening..."
jnemeth@cue.bc.ca (John Nemeth) (12/25/90)
In article <1990Dec21.003030.4379@cocktrice.uucp> mdm@cocktrice.uucp (Mike Mitchell) writes: >I have been attempting to install uupc; I desired to have all executables >in /bin and /usr/bin protected in such a manner that only the execute bit >is on. I changed the mode of all files to reflect the fact that group and >world read/write bits had been removed. > >login cannot exec /bin/sh when it has been changed to 511; this makes it >impossible for a user account to be created and used. When I changed the >protections of /bin/sh to 555, login was able to exec the shell and allow >the user to login. When the login had succeeded in execing a copy of /bin/sh >the next problem to crop up was 'ls: cannot execute'. By changing the >mode of ls from 511 to 555, it began to work. This is an oldy but goody. Fire up ye olde time machine and we find the solution on March 14, 1988. John Nemeth jnemeth@cue.bc.ca From: Marty <uw-beaver!xerox.com!Leisner.Henr> Newsgroups: comp.os.minix Subject: path to allow X bit to be sufficent to exec Date: 14 Mar 88 21:37:04 GMT Sender: uw-beaver!UDEL.EDU!mmdf Source-Info: From (or Sender) name not authenticated. To: info-minix@UDEL.EDU I inserted the following patch into fs/open.c/do_open() to allow the memory manager to read files with only the X bit set. #ifdef ORIGINAL if ((r = forbidden(rip, bits, 0)) != OK) { put_inode(rip); /* can't open: protection violation */ return(r); } #else /* patch to allow X bit to be sufficient to execute file -- MM does it's * own protection checks */ if(who != MM_PROC_NR && ((r = forbidden(rip, bits, 0)) != OK)) { /* allow MM to open up anything he wants */ put_inode(rip); /* can't open: protection violation */ return(r); } #endif Since the memory manager goes through mm/utility/allowed to check file permissions, I'm suspending access checks in fs on mm open calls. Kinda kludgey, but seems to do what I want without any bad side effects. Anyone have any better ideas? I suppose a cleaner way may be to define a special open bit which becomes something like EXEC_ONLY. It looks to be reasonable to perhaps push off the access level checking in mm/utility/access to the file system. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:henr801c:xerox UUCP: nsc!nscimg!amps!marty