ESC1332@ESOC (K.Keyte) (07/03/87)
Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does not, as the mkdir and rmdir are just normal file operations. In MINIX, if SETUID is on it means that any user has the permission to create and delete directories anywhere is the file system. I've tried, however, taking the SETUID bit off, but I can't seem to create ANY directories from normal user accounts in this state. Has anyone any experience with this aspect, or can anyone advise me what the situation should be? Karl
lyndon@ncc.UUCP (Lyndon Nerenberg) (07/04/87)
In article <8707030732.a029212@Louie.UDEL.EDU>, ESC1332@ESOC (K.Keyte) writes: > > Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does > not, as the mkdir and rmdir are just normal file operations. Hate to disappoint you, but... -rwsr-xr-x 1 root bin 14378 Mar 9 1985 /bin/mkdir -rwsr-xr-x 1 root bin 14580 Mar 9 1985 /bin/rmdir This taken from a machine running System V.
rmtodd@uokmax.UUCP (Richard Michael Todd) (07/04/87)
In article <8707030732.a029212@Louie.UDEL.EDU> ESC1332@ESOC (K.Keyte) writes: > >Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does >not, as the mkdir and rmdir are just normal file operations. In MINIX, if >SETUID is on it means that any user has the permission to create and delete >directories anywhere is the file system. I've tried, however, taking the >SETUID bit off, but I can't seem to create ANY directories from normal user >accounts in this state. Standard UNIX? Whose UNIX do you mean by "Standard"? On the only UNIX system besides MINIX which I have access to (BSD4.2), mkdir and rmdir are, as you say, not set-uid. BUT, this is because BSD4.2 has mkdir() and rmdir() system calls which can be executed by any user. MINIX is based on Version 7 UNIX, and it is my understanding that V7 didn't have mkdir() or rmdir(). On MINIX, one has to use the system call mknod() to create a dir., and unlink() to remove one. Only root can use unlink() to unlink directories, and since mknod() can also create device special files, its use is also restricted to root. The mkdir and rmdir programs do contain code to check, using the access(2) system call, whether the real user has permission to write in the parent directory. Alas, the access call doesn't work as it should. For the reason behind this, look in the book's listing, starting at line 11757 (file fs/protect.c), for the access call handler code. Access calls forbidden(), the next subroutine in the listing, to see if the user has permission to do the specified function. Access passes a 1 in the third argument, to tell forbidden to do its tests with the real uid. (All the other calls to forbidden() are to check against euid.) Forbidden() starts out (line 11797) by setting test_uid and test_gid to whichever uid and gids are to be checked, according to the third parameter. However, at the next line (line 11800) is: if (super_user) { perm_bits = 07; } else { ... selecting which set of mode bits to test (user, group,other... Super_user is a global variable set whenever the EFFECTIVE uid is root, which is always when called from a set-uid root utility. Thus, whenever a set-uid root program makes an access(2) call, it never refuses permission. I haven't yet had a chance to try fixing it (having just only learned that the bug exists), but it should be fixable by changing the above test from if (super_user) { to if (test_uid == SU_UID) { thus testing whichever uid (real or effective) is requested by forbidden's caller. -------------------------------------------------------------------------- Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (07/04/87)
in article <1478@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says: -> -> In article <8707030732.a029212@Louie.UDEL.EDU>, ESC1332@ESOC (K.Keyte) writes: ->> ->> Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does ->> not, as the mkdir and rmdir are just normal file operations. -> -> Hate to disappoint you, but... -> -> -rwsr-xr-x 1 root bin 14378 Mar 9 1985 /bin/mkdir -> -rwsr-xr-x 1 root bin 14580 Mar 9 1985 /bin/rmdir -> -> This taken from a machine running System V. Ultrix 1.2: -rwxr-xr-x 1 root system 9216 Feb 19 1986 /bin/mkdir -rwxr-xr-x 1 root system 9216 Feb 19 1986 /bin/rmdir Sun 3.2: -rwxr-xr-x 1 root staff 16388 Sep 15 1986 /bin/mkdir -rwxr-xr-x 1 root staff 16384 Sep 15 1986 /bin/rmdir So why does SysV need them suid and not 4bsd? Mike Khaw internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
mmason@psu-cs.UUCP (Mark C. Mason) (07/04/87)
In article <8707030732.a029212@Louie.UDEL.EDU> ESC1332@ESOC (K.Keyte) writes: > >Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does >not, as the mkdir and rmdir are just normal file operations. In MINIX, if >SETUID is on it means that any user has the permission to create and delete >directories anywhere is the file system. I've tried, however, taking the >SETUID bit off, but I can't seem to create ANY directories from normal user >accounts in this state. In non-4.[23] versions of UNIX, mkdir and rmdir must be suid to root as they call mknod(2) directly (which only root can execute). Though I haven't actually looked, ownership and permissions are probably checked from within user mode. This caused a security problem (in fact mentioned on page 282 in THE BOOK under "Famous Security Flaws") since mkdir created a root owned directory with mknod(2), then called chown(2) to set owner- ship, creating a small window of opportunity. Starting with BSD 4.2 UNIX, the problem was addressed by creating a new system call, mkdir(2), which does the whole operation from within the kernel (this, in part, is why I habitually refer to non-BSD4.[23] versions of UNIX as "pre-BSD" :-). Mark tektronix!psu-cs!mmason
allbery@ncoast.UUCP (Brandon Allbery) (07/06/87)
As quoted from <14338@teknowledge-vaxc.ARPA> by mkhaw@teknowledge-vaxc.ARPA (Michael Khaw): +--------------- | -rwxr-xr-x 1 root staff 16388 Sep 15 1986 /bin/mkdir | -rwxr-xr-x 1 root staff 16384 Sep 15 1986 /bin/rmdir | | So why does SysV need them suid and not 4bsd? +--------------- NOT AGAIN!!!!! BSD has system calls mkdir() and rmdir() which deal with "." and "..", and rmdir() deals with directory not empty. Therefore, they can be used by non- root processes. USG does not. Directories are created with mknod() and removed with unlink(); neither handles "." or "..". As a result, mknod() and unlink(dir) are root- only, so that only programs that know to handle "." and ".." will munge directories. (System V r3 apparently has mkdir() now, from what I hear.) ++Brandon -- ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery <BACKBONE>!cbosgd!ncoast!allbery (NOW!!!!) aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery Mentor, OH 44060-4101 necntc!ncoast!allbery@harvard.HARVARD.EDU (Internet) +01 216 974 9210 ncoast!allbery@CWRU.EDU (CSnet -- if you dare) NCOAST ADMIN GROUP Brandon Allbery on 157/504 (Fidonet/Matrix/whatever) * ncoast -- Public Access UN*X -- (216) 781-6201, 24 hrs., 300/1200/2400 baud * * ncoast is proud to be carrying alt.all -- contact me for more information *
mpl@sfsup.UUCP (07/06/87)
In article <8707030732.a029212@Louie.UDEL.EDU>, ESC1332@ESOC (K.Keyte) writes: > > Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does > not, as the mkdir and rmdir are just normal file operations. I don't know what you consider "standard", but here at AT&T, we put 'em on our mkdir and rmdir. > In MINIX, if > SETUID is on it means that any user has the permission to create and delete > directories anywhere is the file system. I don't have my MINIX source with me, but I'd be surprised. Mkdir and rmdir use access(2) to check permissions before they let the user do what he's trying to do. > I've tried, however, taking the > SETUID bit off, but I can't seem to create ANY directories from normal user > accounts in this state. > > Has anyone any experience with this aspect, or can anyone advise me what the > situation should be? that's my experience, and my advice is put on the s-bits. That's what they're there for.
madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) (07/11/87)
In article <14338@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) writes: >in article <1478@ncc.UUCP>, lyndon@ncc.UUCP (Lyndon Nerenberg) says: >-> >-> In article <8707030732.a029212@Louie.UDEL.EDU>, ESC1332@ESOC (K.Keyte) writes: >->> >->> Does everyone have SETUID on their mkdir and rmdir? Standard UNIX does >->> not, as the mkdir and rmdir are just normal file operations. >-> >-> Hate to disappoint you, but... >-> >-> -rwsr-xr-x 1 root bin 14378 Mar 9 1985 /bin/mkdir >-> -rwsr-xr-x 1 root bin 14580 Mar 9 1985 /bin/rmdir >-> >-> This taken from a machine running System V. > >Ultrix 1.2: >-rwxr-xr-x 1 root system 9216 Feb 19 1986 /bin/mkdir >-rwxr-xr-x 1 root system 9216 Feb 19 1986 /bin/rmdir > >Sun 3.2: >-rwxr-xr-x 1 root staff 16388 Sep 15 1986 /bin/mkdir >-rwxr-xr-x 1 root staff 16384 Sep 15 1986 /bin/rmdir > >So why does SysV need them suid and not 4bsd? > >Mike Khaw Perhaps BSD (and BSD'ish) UNIX supplies programs that make use of the setuid() series of functions. You will notice that all of those programs are owned by root -- therefore, setting the effective uid to root (possible because root owns the program, right?) will allow root-only function calls. (note that I don't usually use the setuid() functions, so I may have confused the notions of "real uid" and "effective uid", but the idea still holds). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd H H | ARPA: madd@bucsb.bu.edu H-C-C-OH <- heehee +---------+---------------------------------- H H | "We are strangers in a world we never made"
lee@unmvax.UNM.EDU (Lee Ward) (07/12/87)
Since 4.2 (actually one of the extended 4.1 releases but I forget which one)
there have been mkdir() and rmdir() system calls. On earlier releases and
AT&T, I suppose (I *know* up to V7), the directories were crafted and
removed by utilities. I guess minix does it this way too?
--Lee
--
--Lee (Ward)
{ucbvax,convex,gatech,pur-ee}!unmvax!leeESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) (07/14/87)
galvin@UDEL.EDU replied to my comment about standard UNIX NOT having the SETUID bits on mkdir and rmdir. Well I accept that some Unices (sic) do have the SETUID, but I am also quite aware by now that others (where mkdir and rmdir are actual internal system calls rather than mknod/link & unlink calls) do NOT have the SETUID. The simple fact is that MINIX does have the SETUID, and it's use of the 'access' routine is not quite correct since it doesn't really check the real uid, because 'access' thinks that it's the super-user, so blindly grants all access. This allows ANY user to create and delete ANY directory ANYWHERE with the mkdir and rmdir as they are (within the normal limitations). I have patched the code to correct this situation, and it now works as it does on UNIX. Karl Keyte
galvin@UDEL.EDU (James M Galvin) (07/14/87)
> galvin@UDEL.EDU replied to my comment
Not true. I am having trouble with my software which does the gatewaying.
It is not setting up the headers in such a way that BITNET likes them. In
particular, I am actually resending the messages, thus I am NOT changing
nor am I setting the From field. But the BITNET listserver (or something)
is taking this and setting the From field to be me. If you look carefully,
most messages have the "reply-to" still set to the actual author.
So, folks, please bear with while I get this straightened out a little
bit at a time. I will announce when everything should be "perfect".
Thanks.
Jim