rbj@icst-cmr.arpa (03/11/87)
? Call it file-system-kudzu. ? ? So, I began to write this shell-script which I hope to pass on to my ? staff which just goes running around checking out whether things seem ? ok with the file system, like is /tmp writeable? are the disks full? ? are various things that probably should be setuid and/or setgid ? actually set that way? ? ? THERE'S A ZILLION GILLION FILES OUT THERE THAT ALL HAVE TO BE SOMEWHAT ? RIGHT TO ALLOW THE SYSTEM TO WORK EVEN SORT OF PROPERLY! ? ? Ok, let's forget executable binaries as in /usr/bin, that's probably ? unavoidable, but all those little 'data base' files (/etc/passwd, ? /usr/lib/uucp/L.sys, /etc/syslog.conf, /mdec, etc etc., the tape reels!) ? ? This is serious, just try to list the critical little files on a piece ? of paper (it'll take several.) ? ? Any thoughts? Or am I the only one who thinks there is a problem? ? I think this is begging for some fundamental thinking. If you are, there is something wrong. I have often bemoaned the fact that /etc contains three different types of files: programs, configuration data (passwd, fstab) and log files (utmp). /usr and /usr/lib are overloaded with random stuff. In fact, /usr is really a misnomer since most users usually live on a different file system. What we really need is a rethinking of where things go and why. Sun has partially done this by making /usr essentially read-only, with symbolic links to /private for writeable (and config?) files. But they have only solved the problem halfway, keeping the basic organization (maybe it is good that they didn't unilaterally redefine everything!). I once did the same thing with my system, using symbolic links to relocate writable files elsewhere, and then mounting /usr read only. It would even be nice to be able to physically mount the entire system disk read only and then throw the write protect switch. Some people have done this, but you must require two disks and swap on the second. We need to have a basic reorganization: all log files go in /log, all daemons go in /daemon, all config files go in /conf. And are we to minimize the root system, or fold /usr in as well? My system packs are rm03's or equivalent (67M) with the last 33440 sectors in the B partition and the rest as the A partition, containing both root & usr. I would like the POSIX committee (or somebody equivalent) to address this issue, altho I admit it is premature at this stage. First we have to define what unix is before we redefine it. ? -Barry Shein, Boston University (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> Why did Paul Simon name his album after Elvis Presley's house?
guy@gorodish.UUCP (03/12/87)
>I would like the POSIX committee (or somebody equivalent) to address >this issue, altho I admit it is premature at this stage. First we have >to define what unix is before we redefine it. I would like the POSIX committee to stay the heck away from this issue, as it's not its business to say where various files live. Many of the files being discussed here should NOT be accessed directly by applications; applications should go through a standard interface to perform various functions, and it's the business of the implementation of that interface to say where the files live, if the implementation uses files at all. (E.g., there IS no "/etc/passwd" in POSIX; there are "getpwent", "getwpuid", and "getpwnam" functions, which is as it should be. It is not the business of any standard to say anything whatsoever about a file named "/etc/passwd" or any file like it.) POSIX isn't trying to define UNIX. It's trying to define a standard interface to various operations, modeled after the interface defined in UNIX; this interface need not be implemented on top of anything even remotely resembling UNIX.
mouse@mcgill-vision.UUCP (03/25/87)
In article <14909@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: >> I would like the POSIX committee (or somebody equivalent) to address >> this issue [re /etc/passwd] > I would like the POSIX committee to stay the heck away from this > issue, as it's not its business to say where various files live. > [...] > (E.g., there IS no "/etc/passwd" in POSIX; there are "getpwent", > "getwpuid", and "getpwnam" functions, which is as it should be. It > is not the business of any standard to say anything whatsoever about > a file named "/etc/passwd" or any file like it.) I agree with you in principle, Guy, but in this case I disagree, since there is no putpwent() or analogous function. If you completely hide the internal structure you then must provide an interface with full functionality. Given just the getpw* functions, there's no way to change the passwd database, which is clearly necessary for any real system. Don't just say that providing chsh, passwd, and chfn programs (or equivalents) is enough; it isn't. We wanted a chsh/chfn/passwd suite of programs with functionality somewhat different from the provided versions. It is unacceptable to be unable to do this sort of thing. der Mouse Smart mailers: mouse@mcgill-vision.uucp USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse think!mosart!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu
guy@gorodish.UUCP (03/28/87)
> Given just the getpw* functions, there's no way to change the passwd > database, which is clearly necessary for any real system. Yes. But is it necessary to provide a *portable* way to write applications to change it? You can change the UAF under VMS, but you can't do it by using the same technique that the "passwd" command uses (I don't know whether there is a documented programmer's interface that lets you change the UAF or whether you'd have to use DEC's commands to do so). Heck, you can't even quite change the password file under *4.3BSD* by using the same technique that the "passwd" command on other flavors of UNIX uses - you also have to update the DBM database. > Don't just say that providing chsh, passwd, and chfn programs (or > equivalents) is enough; it isn't. We wanted a chsh/chfn/passwd suite > of programs with functionality somewhat different from the provided > versions. It is unacceptable to be unable to do this sort of thing. You may be able to do it; you may just have to write different code to do it on different systems. There is a tradeoff here; by specifying more characteristics of the POSIX interface, you increase the number of applications that can be written to the POSIX interface, and thus the number of portable applications - but you also *de*crease the number of possible implementations of the POSIX interface. Is it worth reducing the number of possible POSIX interface implementations by, say, 10% in order to increase the number of portable applications by .1%?
ed@mtxinu.UUCP (03/31/87)
>> Given just the getpw* functions, there's no way to change the passwd >> database, which is clearly necessary for any real system. > >Yes. But is it necessary to provide a *portable* way to write >applications to change it? Yes, it is. >> Don't just say that providing chsh, passwd, and chfn programs (or >> equivalents) is enough; it isn't. We wanted a chsh/chfn/passwd suite >> of programs with functionality somewhat different from the provided >> versions. > >You may be able to do it; you may just have to write different code >to do it on different systems. There is a tradeoff here; by >specifying more characteristics of the POSIX interface, you increase >the number of applications that can be written to the POSIX >interface, and thus the number of portable applications - but you >also *de*crease the number of possible implementations of the POSIX >interface. Is it worth reducing the number of possible POSIX >interface implementations by, say, 10% in order to increase the >number of portable applications by .1%? I don't see how specifying a procedural interface to the password file (which I expect would do the job) that is complete - i.e. includes routines for writing the file as well as reading it - limits the number of implementations. It does make them somewhat more complex, but it also makes them more robust. What's wrong with putpwent(), and others like it? -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
guy@gorodish.UUCP (03/31/87)
> >Yes. But is it necessary to provide a *portable* way to write > >applications to change it? > > Yes, it is. Necessary to whom? The number of applications that update the password file is small. Those applications don't *have* to be written in a portable fashion; you can use #ifdefs for UNIX, VMS, etc. if you want. > I don't see how specifying a procedural interface to the password file > (which I expect would do the job) that is complete - i.e. includes routines > for writing the file as well as reading it - limits the number of > implementations. It does make them somewhat more complex, but it > also makes them more robust. Specifying a procedural interface to the password file isn't the problem. Specifying one that works on *all* POSIX-conforming systems, regardless of what OS they began life as, is. Consider an OS that stores more data in its moral equivalent of the password file than UNIX does. "getpwent" and company don't cause problems; you just throw the extra data away. A routine to change a record might even be doable; you don't modify the fields that aren't in the POSIX "struct pwd" (although this reduces the *usefulness* of this interface - you may not want to use the nominally portable password file updater, since it won't let you change all the fields). But what do you do about *adding* records, especially if you *can't* supply a default for the missing fields? > What's wrong with putpwent(), and others like it? "putpwent" is, at best, only a small part of a procedural interface to the password file. It is just a routine to write out a "struct pwd" in the form of a UNIX password file entry. The System V "passwd" command knows where the password file is, and knows that it has to write to a *temporary* file using "putpwent" and then rename the temporary file. In order to make "putpwent" useful as a semi-portable interface to the password file, you'd need an "open the password file for writing" routine that opened a temporary file, and a "close the password file" routine that did the appropriate rename of the temporary file and regenerated the DBM database on systems that provided a DBM form. Even with that, I'm not convinced you could write a program that anybody using a VMS with a POSIX-conforming interface would care to use. If the only systems that this application is interesting on are UNIX systems, you might as well just gut the standard "passwd" command and reuse its code - or, lacking source, rewrite it - and not worry about portability (or put the DBM update code inside "#ifdef BSD4_3" or something like that). (Heck, there are even problems with "*get*pwent". A number of programs "know" that the password file is a sequential file, and play tricks to avoid repeated searches of the password file caused by repeated calls to "getpwuid" or "getpwnam". However, if the password file is indexed in any reasonably-efficient fashion - or even in a moderately inefficient fashion, if it's really big - this is the wrong thing to do; you're better off using repeated calls to "getpwuid" or "getpwnam".)
jsq@im4u.UUCP (04/07/87)
POSIX in general does not include system administration functions.
You will also find it has getgroups() but not setgroups().
The problem with setpwent() is that, unlike getpwent(), it is
used by only a small number of programs, few of which will be
ordinary applications (I suppose you could call chfn(1) an ordinary
application, but passwd(1) isn't, and it's pretty easy to argue
that the information chfn uses shouldn't be in the passwd database).
Incidentally, you'll usually get more responses out of POSIX participants
in comp.std.unix (formerly mod.std.unix) than in unix-wizards. (Plug plug.)
--
John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq
ARPA Internet and CSNET: jsq@im4u.UTEXAS.EDU, jsq@sally.UTEXAS.EDU