Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!uwm.edu!bionet!ames!dftsrv!iris613!stailey
From: stailey@iris613.gsfc.nasa.gov (Ken Stailey)
Newsgroups: comp.os.minix
Subject: Re: problems with 1.5.0 ST
Summary: mkdir is not setuid anymore
Keywords: kernel, more, sh
Message-ID: <1061@dftsrv.gsfc.nasa.gov>
Date: 5 Mar 90 14:48:12 GMT
References: <2558@ruuinf.cs.ruu.nl> <1186@prles2.prl.philips.nl> <2564@ruuinf.cs.ruu.nl>
Sender: news@dftsrv.gsfc.nasa.gov
Reply-To: stailey@iris613.UUCP (Ken Stailey)
Organization: Goddard Space Flight Center Climate and Radiation Branch
Lines: 16

In article <2564@ruuinf.cs.ruu.nl> frankb@praxis.cs.ruu.nl (Frank Breure) writes:
>In article <1186@prles2.prl.philips.nl> meulenbr@cstw68.prl.philips.nl (Frans Meulenbroeks) writes:
><some stuff deleted>
<more stuff deleted>
>mkdir is a setuid-program and when user "bin" did a "mkdir a" then the owner
>of the new directory "a" was "root" instead of "bin".
>After I did a "chmod 755 mkdir", this problem did not occur,
>isn't this a bit strange ????
The old version of mkdir(1) used to call mknod(2), but in 1.5.3 mkdir(1) is
an interface to a new mkdir(2) system call.  You should not setuid mkdir(1)
anymore.  The system call approach is a POSIX requirement.  The old way
is prone to race conditions, causes a lot of damage if a crash happens,
and is a security problem.

INET stailey@iris613.gsfc.nasa.gov
UUCP {backbone}!dftsrv!iris613!stailey