-----BEGIN PGP SIGNED MESSAGE----- On Tue, 5 Jan 1999, D. J. Bernstein wrote: > Venema further claims that ``a set-uid posting program cannot guarantee > user identification.'' That claim is false. The user id is provided by > the standard UNIX getuid() system call. . . . > For the record, nothing here should be interpreted as advocating the > setuid/setgid concept. As I wrote in the qmail documentation in 1995: > > A setuid program must operate in a very dangerous environment: a user > is under complete control of its fds, args, environ, cwd, tty, rlimits, > timers, signals, and more. Even worse, the list of controlled items > varies from one vendor's UNIX to the next, so it is very difficult to > write portable code that cleans up everything. > > Of the six most recent sendmail security holes, three worked only > because the entire sendmail system is setuid. > > But my conclusion was merely to be very, very careful: ``Do as little as > possible in setuid programs.'' The alternatives, such as world-writable > directories, are horrendous. We'll be stuck with setuid and setgid until > UNIX develops a simple, portable, reliable, secure IPC mechanism. In principle, you need to do as little as possible in setuid programs, I agree. But if all you need to do is post a file into an area which does not have world writability but does have group writability, and you want accountability, the best, and probably easiest, way to accomplish this without the need for excess code for uid switching (which is tricky to deal with especially with setuid-to-root programs) is the setgid bit and a group-writable directory. I see no real need for a setuid program in this case. I did a test on my box at home with just a copy of touch(1) with the setgid bit set. I created a group, "test", for the purpose of this demonstration. Then I created /var/test owned by group "test" and set with a mode of 770. Linux/ianj@narshe:~$ ls -la /var | grep test drwxrwx--- 2 root test 1024 Jan 6 21:11 test I copied touch to touch-sgid, then set g+s,o-rwx on that file. Linux/root@narshe:~# ls -la `which touch-sgid` - -rwxr-sr-x 1 root test 38532 Jan 6 21:13 /bin/touch-sgid* Now, I execute the following commands: Linux/ianj@narshe:~$ touch-sgid /var/test/blah2 Linux/ianj@narshe:~$ ls -l /var/test ls: /var/test: Permission denied Surprise, surprise. Now, root the box: Linux/ianj@narshe:~$ su - Password: (password I'm not supposed to say) NOW, let's do it. Linux/root@narshe:~# ls -la /var/test total 2 drwxrwx--- 2 root test 1024 Jan 6 21:14 ./ drwxr-xr-x 20 root root 1024 Jan 6 21:11 ../ - -rw------- 1 ianj test 0 Jan 6 21:14 blah2 (The file has those permissions because my normal umask is 077.) This was just with stock touch(1) under Slackware Linux, only with the setgid bit set. Since UIDs on the process never changed, only the GID, no need for the getuid() call. That's how the postdrop program which came with Postfix Beta 981230 works. You set /var/postfix/maildrop to 770 (or 730, take your pick) with the group ownership to a non-populated group, say "maildrop". Then, you tell postdrop to run setgid so it can write to the maildrop directory. No need for more ugly code associated with setuid programs. Setuid does have its uses, however. But in this case, I do not see any real need for it if all you need to do is drop a file in a directory. Daemon programs running as root, such as master from Postfix, takes care of the rest. - --Ian. - --- Ian R. Justman (ianjat_private) CalWeb Internet Services Technical Support/Night Administrator Office: (916) 641-9320 Finger ianjat_private for my public PGP key. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQEVAwUBNpRJH0yc+bfQRhUBAQGT/wf/TNc1uLqgESVsJuRRbvxNMRJNdWfT6npD 1ByKWdyyHjvEyCQCTrMF8TpfUkVbI/Qb0w7t2iKFztQtRVTORFgWu69S08VhfEx5 UQn55fmGecytlYeB9fPBXESu5c1YSVXvHspszPblHoso5Nh/A1dG4fQ1ywt2mrrJ ONQWmX0rGLkG98Uvgb/JM6e7uZoKIheFPZ1hFacY5bfqJCnNOeFVWjtbC1Yb8J1W h39HvsHzrf7l684kM9mLfGHlNxhSKoY/ZX97vJVL2fpAb0La2InLCazZBaH0v63c fhO9VmzN5kIl5PeiKGoyQPrEL5CxkL5ayjJZfVZyzq0GcF3+97NkPA== =1NCj -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:56 PDT