baker@nodecg.ncc.telecomwa.oz.au (mark baker 4206813) (04/10/91)
One of my 386 machines running Xenix 2.3.2 has suddenly refused to let
any user, including root, from making a directory. The mkdir test command
generates
mkdir: cannot make directory test
I can create files ok.
Any clues please!
Mark Baker Phone: +61 9 4206813
Network Computer Centre Fax: +61 9 4208851
5th Floor Telecom Centre ACSNET: baker@telecomwa.oz
80 Stirling Street, Perth Inet: baker%telecomwa.oz@uunet.uu.net
Western Australia 6000gwyn@smoke.brl.mil (Doug Gwyn) (04/18/91)
In article <1991Apr10.090338.4967@nodecg.ncc.telecomwa.oz.au> baker@nodecg.ncc.telecomwa.oz.au (mark baker 4206813) writes: >One of my 386 machines running Xenix 2.3.2 has suddenly refused to let >any user, including root, from making a directory. On many UNIX implementations, presumably including yours, "mkdir" must be installed set-UID 0 in order to work. I would guess that somebody changed the owners of the system utilities, or their protection modes, or something like that.
veit@du9ds3.uni-duisburg.de (Holger Veit) (04/18/91)
In <15884@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Apr10.090338.4967@nodecg.ncc.telecomwa.oz.au> baker@nodecg.ncc.telecomwa.oz.au (mark baker 4206813) writes: >>One of my 386 machines running Xenix 2.3.2 has suddenly refused to let >>any user, including root, from making a directory. >On many UNIX implementations, presumably including yours, >"mkdir" must be installed set-UID 0 in order to work. >I would guess that somebody changed the owners of the system utilities, >or their protection modes, or something like that. I also first guessed that. Mkdir on Sys5 systems depends on the mknod(2) system call which is executable only by root. Mknod allocates a new Inode, which is then linked into the tree, the directory file is then filled with the '.' and '..' entries. Mknod requires root-only execution because you can easily destroy file system consistency with wrong usage or faults. (the root always knows what s/he does :-))))) But Mark Baker said above, that even root cannot make a directory. So, setuid 0 for mkdir is obviously not the problem. I think the effect can be simulated by patching the /etc/passwd root entry to another UID than 0, which would be a very ugly thing if it happened... :-) Hope this helps. Holger -- | | / Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge | |/ Dept. f. Dataprocessing |
barmar@think.com (Barry Margolin) (04/19/91)
In article <veit.671986606@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes: >In <15884@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>On many UNIX implementations, presumably including yours, >>"mkdir" must be installed set-UID 0 in order to work. >But Mark Baker said above, that even root cannot make a directory. So, setuid 0 >for mkdir is obviously not the problem. No, it still could be the problem. Maybe his mkdir is still setuid, but with a non-root owner. When root runs it, his UID is changed to that of the incorrect owner, and then he can't do the privileged system call. Remember, setuid even affects the superuser. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jim@segue.segue.com (Jim Balter) (04/20/91)
In article <veit.671986606@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes: >In <15884@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>I would guess that somebody changed the owners of the system utilities, >>or their protection modes, or something like that. > >But Mark Baker said above, that even root cannot make a directory. So, setuid 0 >for mkdir is obviously not the problem. Watch that word "obviously". Changing owner on a setuid file doesn't clear the setuid bit, so mkdir could have ended up setuid to someone other than root. If the effective user is not root, the mknod will fail even if root is the real user.