Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!cwruecmp!hal!ncoast!allbery From: allbery@ncoast.UUCP Newsgroups: comp.bugs.sys5 Subject: Re: Unlinking "." Message-ID: <2356@ncoast.UUCP> Date: Sat, 11-Apr-87 15:02:20 EST Article-I.D.: ncoast.2356 Posted: Sat Apr 11 15:02:20 1987 Date-Received: Sun, 12-Apr-87 05:49:25 EST References: <1059@cci632.UUCP> <5715@brl-smoke.ARPA> <736@killer.UUCP> <16186@sun.uucp> <753@killer.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.bugs.sys5 Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 117 As quoted from <753@killer.UUCP> by jfh@killer.UUCP (John Haugh): +--------------- | In article <16186@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: | > Second of all, there are some annoying restrictions caused by the | > lack of these calls; a program that is set-UID to somebody other than | > "root" can't create or destroy directories using its set-UID | > protection, since the "mkdir" and "rmdir" commands must be set-UID | > "root" and, as such, will throw away the old set-UID privileges when | > they are run (remember, vanilla V7, S3, and S5 won't let you set the | > real UID to match the effective UID). | > | I haven't looked at the documentation for S5R3 yet, so I really don't know | what I am talking about here. It seems that you can always spawn a mkdir(1) | or rmdir(1) sub-process to create/delete your directories, but if the | mkdir(2) and rmdir(2) require you to be root in the first place (can you +--------------- No, you can't. Please note that my UNaXcess Conferencing provides its own mkdir command (mkconf) because the UC directories are not readable or writeable by anyone but the owner of UC, and the "ua" executable runs setuid. Therefore a mkdir will FAIL ALWAYS because it runs as uid=who-ran-ua, euid=root but UC needs uid=owner-of-ua. This is (to say the least) a bad solution to a bad problem. Unfortunately, there is no GOOD solution short of moving mkdir() into the kernel. Why don't I just allow anyone to scribble in the UC directories? Ever heard of security? +--------------- | > the Sun "vnode" mechanism or the S5R3 File System Switch can support | > many *different* types of file systems, not all of which would permit | > you to create directories using the code from the old-style "mkdir" | > command or to remove them using the code from the old-style "rmdir" | > command. | > | As for the Sun systems you work on, many of the features you are adding | are not used by developers because of the differences between V7, BSDxxx | and USG Systems III, IV and V. If you would like some proof of this, | talk with some at Uniplex Integration Systems. The applications they | develope are written to use the minimal subset of features from all Unix | versions. +--------------- Counterexample: Informix Software, Inc. Informix-SQL uses directories, and is capable of being networked. (In fact, they also use my solution: look up $INFORMIXDIR/lib/makedir.) +--------------- | It is possible to fix the races in the kernel without adding the calls. | And as for making the system fatter, when I was installing USG 4.0 on | a PDP-11/45 about 5 or 6 years ago, the system almost didn't fit because | it had gotten so fat. When USG 5.0 came out in 81 or 82, it didn't fit | because there was so much junk in it. As more stuff is added, it gets | harder and harder to cram Unix into the limited memory that many of these | machines have. Sure, M68000's don't have a 64K text space. But, many | modern CPU's have such squirrely addressing that a massively huge Unix | kernel really puts a dent in either the performance, or the amount of | available memory. +--------------- And lack of them really puts a dent in database operations -- the SINGLE biggest use of computers in business. System V provides THREE kinds of mutual-exclusion primitives: record locking (Vr3), semaphores, and messages (see a good book on message-passing systems for info on how to use messages for mut/ex). V7 supplies NONE, and databases can therefore get into trouble. BTW, what do you define as a modern CPU? PDP/11? iAPXx86? I laugh. The first is dated, the second is a glorified 8080 no matter what its address space it. (80386 is the exception. Intel finally decided to build a CPU that wasn't an 8080 with cheap bank switching.) MODERN CPUs are 68020, 32032, MicroVAX, etc. -- all of which handle the address space needed for real work in the real world (read databases). +--------------- | Yes, I run Version 7 at home. Running size(1) on /unix gives me numbers | something like 57000+20000+32000 or about 110K. But have you looked at | YOUR kernel lately? Here are two 5.2 systems I use: | | 3B2/400: 168704+25576+801536=972K | Plexus P/60: 247060+18528+162740=418K +--------------- So? (NB: I use a P/60 with SysV at work.) If you need the features, they have to go in. And I dare you to set up a multiuser database under V7 that will NEVER suffer from lock problems due to race conditions. +--------------- | There used to be one way to do everything in Unix. And that was picked | to be the most flexible one possible. I guess times have changed. I don't | know if you paid any attention to the discussion about trashed file names, | but it seems to me that a system call that won't let you unlink a directory | with file entries in it is going to prevent the usual fix to this problem - | unlink the directory and run fsck(1). +--------------- The correct fix is to fsdb the directory. The REAL correct fix is to make fsck put files with bad names in lost+found. Flexible -- fine. `.' and `..' are in fact flexible. TOO flexible. UNIX went to directed graphs (and made `.' and `..' obsolete) when it was discovered that arbitrarily linked directories could NOT be checked for consistency. If you disagree, remove setuid from mkdir and rmdir and tell the kernel that it's okay for nonroot to link and unlink directories; then you have `.' and `..' in their most flexible form, and you can kiss fsck goodbye. Soon afterward you can kiss your file system goodbye. Small is beautiful, but too small is useless and therefore ugly. ++Brando -- .--, .-----------, Brandon S. Allbery cbatt!cwruecmp!ncoast!allbery Y .-, .-, .-, aXcess Company ncoast!allbery@case.CSNET .--,| +-' `-, `-, 6615 Center St. #A1-105 (@relay.cs.net) | A `-' `-' `-' Mentor, OH 44060-4101 MCIMail: BALLBERY `--' `-----------' +01 216 974 9210 (UANet: "UANet FlagShip":Sysop)