japplega@csm9a.UUCP (Joe Applegate) (07/01/87)
Contrary to my previous posting commenting out the super_user check in
open.c (fs) did not solve my problem... only root can link or unlink
directories.... I finally have resolved myself to logging in as root
and then su to bin or jra... when I have to mkdir or rmdir I ^d back
to root... a real kludge!!!
I also discovered that when the system is recompiled only root can
sucessfully issue a su?
Am I missing something here or is there a marked difference between the
supplied binaries and the published code.... none of these problems appear
until I recompile mm and fs, which is nessecary to change the root device
I could just use root all the time but that sort of violates the protection
scheme... and chewing up 200 - 240K of the sparse memory resources of a
PC for an unnessecary ram disk IS a total WASTE!
Joe Applegate - Colorado School of Mines Computing Center
{seismo, hplabs}!hao!isis!csm9a!japplega
or
SYSOP @ M.O.M. AI BBS - (303) 273-3989 - 300/1200/2400 8-N-1 24 hrs.
*** UNIX is a philosophy, not an operating system ***
*** BUT it is a registered trademark of AT&T, so get off my back ***
mpl@sfsup.UUCP (07/02/87)
In article <462@csm9a.UUCP>, japplega@csm9a.UUCP writes: > Contrary to my previous posting commenting out the super_user check in > open.c (fs) did not solve my problem... only root can link or unlink > directories.... I finally have resolved myself to logging in as root > > I also discovered that when the system is recompiled only root can > sucessfully issue a su? > The solution is as follows: "mkdir" should be set-user-id and owned by root. do a "chown root mkdir" and a "chmod 4711 mkdir" "mv" calls a program called "mv_dir" to actually move directories. "mv_dir" should also be mode 4711, owned by root. Finally, "su" should have the same mode and owner.
rmtodd@uokmax.UUCP (Richard Michael Todd) (07/04/87)
In article <461@csm9a.UUCP> japplega@csm9a.UUCP (Joe Applegate) writes: >the book or on the fs directory.... case in point.... only uid 0 (root) can >call mknod()... that fits in well with the V7 doc... but mkdir.c calls mknod() >to create a directory! Apparently mv does likewise when renaming or moving >a directory... the end result is that if you recompile fs no one but the >super-user can mkdir or mv (directories).... UGGHH... now I will admit that >I am a full fledged novice at UNIX (my background is OS9 and MS-DOS) but it >appears to me that the published source was quietly hacked before compilation >(under PCIX I assume?) to allow all users to mknod()... when I removed the Nope, nothing was hacked. mknod still requires root permission to work. The trick is (in my opinion) one of the cleverest features of UNIX: the set-uid mode bit. If you have a program which has this mode bit set and is owned by root, whenever that program is run it can do any system call that root can-- its "effective uid" is set to root. This way system calls such as mknod are protected by making them executable only by root and not by the average user's programs, yet system programs like mkdir can use mknod() by temporarily assuming root's identity. To tell if a file is in set-uid mode, do a 'ls -l' of it. You should get in the protection mode field something like: rwsr-xr-x The s in the third column indicates set-uid. To make a file so that it runs under root's uid, you first have to change its owner to root (if it isn't already). First, if you're not already logged in as root, su to root. Then type chown root <filename> where <filename> is the name of the file. Then to make it set-uid root, readable and executable by everybody, writable only by root (this is the usual mode for the MINIX programs that need set-uid), type: chmod 4755 <filename> In article <462@csm9a.UUCP> japplega@csm9a.UUCP (Joe Applegate) writes: >open.c (fs) did not solve my problem... only root can link or unlink >directories.... I finally have resolved myself to logging in as root >and then su to bin or jra... when I have to mkdir or rmdir I ^d back Just make sure that the mkdir and rmdir programs are set set-uid root, as I mentioned above. >I also discovered that when the system is recompiled only root can >sucessfully issue a su? Su is another program that requires set-uid to work--you don't want everybody to be able to execute the setuid() system call, but you want su to be able to do so (after it checks the password). >Am I missing something here or is there a marked difference between the >supplied binaries and the published code.... none of these problems appear >until I recompile mm and fs, which is nessecary to change the root device I don't understand this. Assuming you haven't altered the original binaries for the files, they should execute unchanged. Check your original disks for everything in /bin and /usr/bin that's set-uid, and make sure that it is so on your working disk. ___________________________________________________________________________ Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd
simsong@athena.mit.edu (Simson L. Garfinkel) (07/15/87)
In article <613@uokmax.UUCP> rmtodd@uokmax.UUCP (Richard Michael Todd) writes: >The trick is (in my opinion) one of the cleverest features of UNIX: the >set-uid mode bit. If you have a program which has this mode bit set and >is owned by root, whenever that program is run it can do any system call >that root can-- its "effective uid" is set to root. This way system calls I would like to point out that Bell Labs has a patent on the setuid bit. ................................................................simson
alastair@geovision.UUCP (Alastair Mayer) (07/30/87)
In article <1142@bloom-beacon.MIT.EDU> simsong@athena.mit.edu (Simson L. Garfinkel) writes: > >I would like to point out that Bell Labs has a patent on the setuid bit. > >................................................................simson True enough, but that patent was released to the public domain. -- Alastair JW Mayer BIX: al UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!alastair (Why do they call it a signature file if I can't actually *sign* anything?)