paire@imag.UUCP (Eric PAIRE) (04/24/86)
UNIX system V users may have remarqued there is no "mkdir(2)" system call. It is replaced by "mknod(2)", but must be executed only by super-user. Why is it necessary to be super-user for creating an own directory ? I am very very interesting by getting an wizard answer by mail or news. MERCI ! Eric PAIRE Bureau B202 L.G.I. / IMAG B.P. 68 38402 Saint Martin d'Heres Cedex FRANCE UUCP : ......seismo!mcvax!vmucnam!imag!paire
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/28/86)
In article <663@imag.UUCP> paire@imag.UUCP (Eric PAIRE) writes: >UNIX system V users may have remarqued there is no "mkdir(2)" system call. It >is replaced by "mknod(2)", but must be executed only by super-user. Why >is it necessary to be super-user for creating an own directory ? Because mknod() does not create the "." and ".." entries. A non-privileged user on UNIX System V needs to run the "mkdir" command to create a directory. You can do this using system().
guy@sun.UUCP (04/28/86)
> mkdir(2) was a security problem (think about it). What the hell are you talking about? Do you know what the "mkdir" system call actually does? Are you aware that it makes a directory *with the "." and ".." entries included*? It has the same semantics as calling the "mkdir" command (although, unlike the "mkdir" command, it allows a set-UID program to make directories using its effective UID). Furthermore, I'm not sure what this "*was* a security problem" stuff is. This, and the line from the previous article > > UNIX system V users may have remarqued there is no "mkdir(2)" system call. > > It is replaced by "mknod(2)", but must be executed only by super-user. indicate that people think "mkdir" was in some older version of UNIX, but removed from System V. This is totally incorrect. The "mkdir" system call appeared in 4.2BSD. It was not in V7, and wasn't added in S3 or S5. It *is*, however, in the IEEE P1003 Portable Operating System Environment's standard, and as such may well appear in future System V releases. > If you are porting programs that use it to System V, you should #define > it to the equivalent system("mkdir ...") sequence. There is no 100% equivalent "mkdir ..." sequence; as I mentioned above, since "mkdir" is itself a set-UID program, a set-UID program which uses "mkdir" to create a directory can only do so with the privileges of its *real* UID, not its *effective* UID. Also note that the "mkdir" system call takes a "mode" argument, just like "creat", so if you're not doing "mkdir(<path>, 0777)" you'll have to do a "chmod" after making the directory (remember to include the "umask" with whatever mode you change it to, and if you want to be *strictly* equivalent, don't do the "chmod" if the directory already exists!). As for the question > > Why is it necessary to be super-user for creating an own directory ? the answer is that, while the "mkdir" system call creates a complete new directory, with "." and ".." entries, the "mknod" system call merely creates the directory inode and directory entry pointing to it. As such, you could create a directory with no "." or ".." entries, which could cause some confusion and may make "fsck" very unhappy. (Also, "mknod" can create other things, such as, for example, a special file which refers to the disk partition on which the root file system resides; this, obviously, should be restricted to the super-user. If "mknod" made complete directories, it could permit non-super-users to make only inodes of type FIFO and directory.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa
cabo@tub.UUCP (05/01/86)
/***** tub:net.unix-wizar / sun!guy / 9:13 pm Apr 28, 1986*/
[...]
indicate that people think "mkdir" was in some older version of UNIX, but
removed from System V. This is totally incorrect. The "mkdir" system call
appeared in 4.2BSD. It was not in V7, and wasn't added in S3 or S5. It
*is*, however, in the IEEE P1003 Portable Operating System Environment's
standard, and as such may well appear in future System V releases.
/* ---------- */
At the Florence EUUG, Andy Rifkin of AT&T gave a talk about AT&T's RFS
and hinted that SysV Rel3 will have mkdir(2) and rmdir(2), but no rename(2).
Obviously, it must have a mkdir(2) if it is to have separate security
domains the super-users of which are not necessarily super-users in
other domains.
BTW, he also hinted at the way they support ioctl(2)s over the wire:
They just hacked up copyin/copyout to do a reverse RPC to reach into
the process space of the calling process.
He didn't mention how they handle the different pointer sizes and different
ioctl parameter block representations with heterogeneous SysV Rel3 networks;
when I asked him he told me that support for ioctls in hetero networks
would have to wait till a later release...
--
Carsten Bormann, <cabo@tub.UUCP == cabo@db0tui6.BITNET>
...!{mcvax,seismo}!unido!tub!cabo
Communications and Operating Systems Research Group
Technical University of Berlin (West, of course...)hfavr@mtuxo.UUCP (a.reed) (05/06/86)
This is a retraction. When I read > > > UNIX system V users may have remarqued there is no "mkdir(2)" system call. > > > It is replaced by "mknod(2)", but must be executed only by super-user. I assumed that the mkdir(2) referred to by the above was the one I once used on a university system. I answered > > mkdir(2) was a security problem (think about it). To which Guy Harris responded: > What the hell are you talking about? Do you know what the "mkdir" system > call actually does? Are you aware that it makes a directory *with the "." > and ".." entries included*? Now, the mkdir(2) I remembered did not do this. Moreover, G.H. writes that > The "mkdir" system call appeared in 4.2BSD. It was not in V7, > and wasn't added in S3 or S5. It appears that the mkdir(2) I used was a local enhancement BSD later picked up (and fixed the security hole). Mea maxima culpa. Adam Reed <ihnp4!npois!adam>