news@edm.UUCP (news software) (01/10/89)
It seems that there is an OOPS in the way that MKDIRSUB works for 2.11
(We're currently running patch 14).
While defs.dist implies that it should be SET if your system has a mkdir
subroutine, the replacement 'mkdir' definitin in funcs.c is surrounded
by "#IFDEF"s rather than "#IFNDEF"s. The #IFDEF sequence is also ended with
an '#ifdef /* !BSD4_2 */' which has been chnged appropriately.
The other way to fix this (as many probably have) is to DEFINE MKDIRSUB
for SYSV and other braindead systems. (just why IS mkdir an SU function???)
diffs follow:
- - - - - - - - - - - - - - - - -
*** old/funcs.c
--- funcs.c
**************
*** 520,526
}
#endif /* VMS */
! #ifdef MKDIRSUB
/*
* make a directory. Also make sure that the directory is owned
* by the right userid
--- 520,526 -----
}
#endif /* VMS */
! #ifndef MKDIRSUB
/*
* make a directory. Also make sure that the directory is owned
* by the right userid
**************
*** 579,585
#endif
return status;
}
! #endif /* !BSD4_2 */
#ifndef RENAMESUB
rename(from,to)
--- 579,585 -----
#endif
return status;
}
! #endif /* !MKDIRSUB */
#ifndef RENAMESUB
rename(from,to)
--
-------------
Stephen Samuel Disclaimer: You betcha!
{ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve
BITNET: USERZXCV@UQV-MTSdavidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/13/89)
In article <5143@edm.UUCP> news@edm.UUCP (news software) writes: | The other way to fix this (as many probably have) is to DEFINE MKDIRSUB | for SYSV and other braindead systems. (just why IS mkdir an SU function???) On SysV the mkdir system call makes a directory. On BSD systems it makes a directory and creates the . and .. links. If you have a directory with . and .. missing or malformed a lot of applications won't work, particularly backups. SysV allows the superuser to create a directory and put in it what he wishes. BSD decided that convenience wins over power and gave you fsdb to handle the fancy cases. SysV added another mkdir call which also creates the files. This has been out for some time, since V.2.x, and is in V.3. I don't think that making another design decision is "braindead," and using phrases like that brings on o/s wars. Now you know why SysV has mkdir an SU function, because it makes a directory, with full user control, and the average user is better off having it done for him. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
guy@auspex.UUCP (Guy Harris) (01/13/89)
(By this point it's a UNIX issue, not a B News issue.) > On SysV the mkdir system call makes a directory. You're thinking of "mknod", not "mkdir". S5, prior to S5R3, didn't have a "mkdir" system call. > SysV allows the superuser to create a directory and put in it what he >wishes. BSD decided that convenience wins over power and gave you fsdb >to handle the fancy cases. 1) BSD also has "mknod". It even, from a quick glance at the 4.3BSD code, permits you to make directories, just as the S5 one does (not surprising, since they both inherited it from older versions of UNIX). And no, it doesn't seem to create the "." or ".." entries. SunOS's "mknod" creates directories with "." and ".." entries, but not BSD's. 2) BSD *doesn't* have "fsdb". If you want to make a directory with no "." or ".." entries, you can just use "mknod", or perhaps use "mkdir" and remove the entries by hand - assuming, of course, that you're super-user. > SysV added another mkdir call which also creates the files. This has >been out for some time, since V.2.x, and is in V.3. Are you sure it was in some S5R2 release? Perhaps in some 3B2 release. It was added, at least in part, because S5R3 has the File System Switch, and some file system other than the S5 one might have a reason for not implementing "create a directory" as "create a directory node and then make the '.' and '..' links" (it might not even *have* "." and ".." as links, although it'll have to make them work in pathnames). It was also added because S5R3 has RFS, and super-user access is NOT always granted over the wire, for good reason. RFS wouldn't be very transparent if you couldn't create directories on remote machines, and requiring super-user access to be granted over the wire would not have been an acceptable fix for this problem. >I don't think that making another design decision is "braindead," Deciding not to have a non-privileged function for creating directories is, given the existence of mechanisms such as the VFS and FSS mechanism, and distributed file systems such as NFS and RFS, undesirable. Neither of those existed when the decision was originally made. >Now you know why SysV has mkdir an SU function, because it makes a >directory, with full user control, and the average user is better >off having it done for him. The question is not why is "'mknod' of a directory (NOT 'mkdir'!) an SU function?", it's "why isn't there a NON-su 'create a directory' function?" The answer is largely "nobody thought it was necessary when the systems without it were made." It is necessary now. The "mkdir" call wasn't put in because "the average user is better off having it done for him." The "mkdir" command in systems without the "mkdir" call was set-UID to the super-user, so there already existed a mechanism by which users (average or not) could create directories; however, in more modern environments it had the problems listed above (and also was a nuisance if a set-UID program wanted to create directories with the privileges of its effective user ID rather than its real user ID).