tpc@leibniz.UUCP (Tom Chmara) (08/12/88)
Not sure this is a question requiring wizardly knowledge, but I have been informed that NFS is NOT particularly secure; i.e. "root" on one machine can wreak havoc on another (I'm not speaking of removing files from a r-w directory etc). The speaker was not overly clear about what the hole was, but he smugly assured me that he could do much as he pleased if I were to allow him NFS access from a machine on which he was root. Is this a problem with NFS, or with the HP or Apollo versions of NFS? Thanks... ---tpc--- ------------------------------------------------------------------------ "Penguin lust is beautiful!" All the above opinions are my own. Licensing inquiries welcome.
karish@denali.stanford.edu (Chuck Karish) (08/14/88)
In article <126@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: >Not sure this is a question requiring wizardly knowledge, but I have >been informed that NFS is NOT particularly secure; i.e. "root" >on one machine can wreak havoc on another (I'm not speaking of >removing files from a r-w directory etc). The speaker was not >overly clear about what the hole was, but he smugly assured me that >he could do much as he pleased if I were to allow him NFS access from >a machine on which he was root. Is this a problem with NFS, or >with the HP or Apollo versions of NFS? Some implementations of NFS assume that user ID numbers are congruent on server and client. This means that a bad guy can empower a Trojan horse on the remotely-mounted filesystem, then use it from the server machine to get privileged access. This would seem to be a risk only if the user has login access to both machines. Do current versions of NFS provide a way for managers to control mapping of user ID's? IBM's Distributed Services does, but it's not available from other vendors. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
arosen@eagle.ulowell.edu (MFHorn) (08/15/88)
From article <23289@labrea.Stanford.EDU>, by karish@denali.stanford.edu (Chuck Karish): > In article <126@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: >>I have >>been informed that NFS is NOT particularly secure; i.e. "root" >>on one machine can wreak havoc on another An NFS server maps uid 0 from incoming RPC requests to 'nobody', which is configured into the kernel. If 'nobody' is set to 0, then anyone with root access on another machine can get it on yours. The default setting for nobody is (in most implementaions) -2. Also, if you don't export any filesystmes to a particular host, that host can do nothing to your host even if nobody is set to 0. [NFS under Ultrix maps nobody per exported filesystem.] > Some implementations of NFS assume that user ID numbers are congruent > on server and client. This means that a bad guy can empower a > Trojan horse on the remotely-mounted filesystem, then use it from > the server machine to get privileged access. If root access is refused (see above), then the bad guy won't be able to create a set-uid root file on the server. > Do current versions of NFS provide a way for managers to control mapping > of user ID's? The kernel can only map uid 0. Yellow Pages, a service provided with NFS, helps managers maintain a network-wide password file. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
shankar@hpclscu.HP.COM (Shankar Unni) (08/15/88)
> removing files from a r-w directory etc). The speaker was not > overly clear about what the hole was, but he smugly assured me that > he could do much as he pleased if I were to allow him NFS access from > a machine on which he was root. Is this a problem with NFS, or > with the HP or Apollo versions of NFS? Normally, root on a machine (say, A) which NFS-mounts file systems from another machine (say, B) gets the uid -2 on machine B. He (/she/it) thus cannot do much damage on B. However, there is a configurable option to let root on A get a uid of 0 (or anything other than -2) on B. Then of course you're playing with fire... -- Shankar Unni. Hewlett-Packard.
sxn%ingersoll@Sun.COM (Stephen X. Nahm) (08/16/88)
In article <126@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: > The speaker was not >overly clear about what the hole was, but he smugly assured me that >he could do much as he pleased if I were to allow him NFS access from >a machine on which he was root. Is this a problem with NFS, or >with the HP or Apollo versions of NFS? The security problems of NFS are well-known. rlogin has a similar hole. For most of its life, NFS has had only one kind of method of authenticating the user. It is called UNIX authentication, and it uses uids and gids to identify the user, but there is no way for the server machine to *verify* that the user has passed a valid uid. If the user can be root on his machine, he or she can then 'su' to any other user he or she pleases to become. A new authentication method was introduced in SunOS 4.0: DES authentication. With this method, a network-wide identifier is constructed for each user, and a password is associated with that identifier. A user must know the password to be allowed to use a particular network-wide identifier. On a UNIX server, the identifier is translated into a uid. DES stands for Data Encryption Standard, and is used to encode a verifier that the server uses to verify the identity. Please refer to RFC1050 for further details on DES Authentication in Sun's RPC. Most companies that support NFS will support DES authentication in the near future. Steve Nahm Portable NFS/ONC Sun Microsystems Steve Nahm sxn@sun.COM or sun!sxn
chris@mimsy.UUCP (Chris Torek) (08/16/88)
In article <8610@swan.ulowell.edu> arosen@eagle.ulowell.edu (MFHorn) writes: >An NFS server maps uid 0 from incoming RPC requests to 'nobody', which >is configured into the kernel. ... The default setting for nobody is >(in most implementaions) -2. This mapping is almost useless. If I am root on machine sneaky.edu, and want to be anyone else on machine uptight.edu, all I have to do is set my uid on sneaky. Granted, I cannot do anything as uid 0 on uptight, but I can do anything as anyone else. >Also, if you don't export any filesystmes to a particular host, that >host can do nothing to your host even if nobody is set to 0. *snicker* Actually, this almost works in some NFS implementations. In old SunOSes (I have no current ones so I have no idea if it has been fixed there), all I have to do is cobble up a request packet that claims my hostname is one to which you do export some file system, and your mount daemon will believe me. It does not even check the Internet address, just the name I stuff in my request packet! Even if you fix this, all I have to do is make up a suitable file handle. That can be anywhere from trivial (passive spying will show some fine handles) to somewhat hard. What is needed is real authentication. (SunOS 5.0 anyone? :-) ... actually, I understand Sun are working hard on this one.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
yar@basser.oz (Ray Loyzaga) (08/17/88)
>>From: shankar@hpclscu.HP.COM (Shankar Unni) > >> removing files from a r-w directory etc). The speaker was not >> overly clear about what the hole was, but he smugly assured me that >> he could do much as he pleased if I were to allow him NFS access from >> a machine on which he was root. Is this a problem with NFS, or >> with the HP or Apollo versions of NFS? > >Normally, root on a machine (say, A) which NFS-mounts file systems from >another machine (say, B) gets the uid -2 on machine B. He (/she/it) thus >cannot do much damage on B. I don't understand the meaning of much damage?? If you use NFS and only have unix style uid mapping, then a user who is root on his workstation (a very simple act on some really high-volume workstations) can su to any other uid and tamper with files owned by that user on any filesystem that he has been allowed to remote mount. This means that any non-root owned file can be removed, looked at or modified. I tend to call that a lot of damage! > >However, there is a configurable option to let root on A get a uid of 0 >(or anything other than -2) on B. Then of course you're playing with >fire... Well what happens if on SunOS 3.5 you do as root on your workstation on a remote fs mknod ~mydir/mem c 3 0 yup, you end up with a nobody owned copy of /dev/mem. So whats to stop you from using the adb and fixing the remote unix so that nobody = 0?? or that setreuid always works?? It has been done here by one of our pgrads. This form of protection just means that it takes 30 seconds longer to crack an NFS system, I doubt that it is worth the effort. We just admit that it is insecure, curse a little, and make sure that only "good guys" have physical access to the workstations.
mouse@mcgill-vision.UUCP (der Mouse) (08/20/88)
In article <8610@swan.ulowell.edu>, arosen@eagle.ulowell.edu (MFHorn) writes: > An NFS server maps uid 0 from incoming RPC requests to 'nobody', > which is configured into the kernel. [...] The kernel can only map > uid 0. Yellow Pages, a service provided with NFS, helps managers > maintain a network-wide password file. You seem to be confusing NFS with Sun's implementation of NFS (which other vendors have picked up and are selling as part of their own product, though DEC in particular seems to have resisted). Not all NFS servers map incoming uid 0 (an old version of mine didn't). Of those that do, not all are restricted to mapping only uid 0, nor need this be done by the kernel. Not all NFS implementations have YP supplied as well. Some people don't *want* a network-wide passwd file. NFS != Sun's NFS. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
liam@cs.qmc.ac.uk (William Roberts) (09/01/88)
In article <1394@basser.oz> yar@basser.oz (Ray Loyzaga) writes: > >Well what happens if on SunOS 3.5 you do as root on your >workstation on a remote fs >mknod ~mydir/mem c 3 0 > >yup, you end up with a nobody owned copy of /dev/mem. This is not an NFS problem, since it is equally applicable to non-superusers on a local machine: it is simply a hint that mknod should be root-only. :-) -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250
jmc@ptsfa.PacBell.COM (Jerry Carlin) (09/02/88)
In article <604@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes: >This is not an NFS problem, since it is equally applicable to >non-superusers on a local machine: it is simply a hint that >mknod should be root-only. :-) This is not a problem in the System V.2 world. Not only does mknod.c check for superuser (easily bypassable) but mknod(2) does not allow anyone but root to mknod anything but FIFO's. -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
sow@eru.mt.luth.se (Sven-Ove Westberg) (09/02/88)
In article <604@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes: |In article <1394@basser.oz> yar@basser.oz (Ray Loyzaga) writes: |> |>Well what happens if on SunOS 3.5 you do as root on your |>workstation on a remote fs |>mknod ~mydir/mem c 3 0 |> |>yup, you end up with a nobody owned copy of /dev/mem. | |This is not an NFS problem, since it is equally applicable to |non-superusers on a local machine: it is simply a hint that |mknod should be root-only. :-) On all SunOS that I have access to (3.2, 3.5, 4.0) I got this when I try. mknod: must be super-user So it is a NFS problem. Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. Internet: sow@cad.luth.se
guy@gorodish.Sun.COM (Guy Harris) (09/03/88)
> > >Well what happens if on SunOS 3.5 you do as root on your > > >workstation on a remote fs > > >mknod ~mydir/mem c 3 0 > > > >yup, you end up with a nobody owned copy of /dev/mem. > > > >This is not an NFS problem, since it is equally applicable to > >non-superusers on a local machine: it is simply a hint that > >mknod should be root-only. :-) > > This is not a problem in the System V.2 world. Not only does mknod.c > check for superuser (easily bypassable) but mknod(2) does not allow > anyone but root to mknod anything but FIFO's. 1) mknod(2) is super-user only, except when asked to create FIFOs, in *every* version of UNIX I know of. It's hardly just S5R2.... 2) The problem cited *is* an "NFS problem", in the sense that the UID mapping performed by the usual NFS implementations is its cause. If "non-superusers on a local machine" were permitted to create special files other than FIFOs with "mknod", the files wouldn't be owned by "nobody" unless somebody did more than just removing the super-user check in "mknod" when they changed UNIX to allow non-superusers to create such files. Any remote file system where you do UID mapping will potentially have this problem, unless it doesn't map creator UIDs.
guy@gorodish.Sun.COM (Guy Harris) (09/06/88)
> On all SunOS that I have access to (3.2, 3.5, 4.0) I got this when I try. > > mknod: must be super-user > > So it is a NFS problem. The only line of reasoning that I can see to get from the premise "this happens on all versions of SunOS that I've tried it on" to the conclusion "it must be an NFS problem" is "Sun invented NFS, so if it happens on all versions of SunOS it must be an NFS problem". However, this is one of the silliest lines of reasoning I have ever had the misfortune to encounter, so obviously it wasn't the line of reasoning being used here. Any other line of reasoning, however, is likely to be equally silly, since the reason the "mknod" command prints that message is that it contains the lines if(getuid()) { fprintf(stderr, "mknod: must be super-user\n"); exit(2); } which certainly have nothing whatsoever to do with NFS. In fact, those lines came from the System V "mknod", and were added when named pipes were added to SunOS, because we picked up the S5R2 "mknod" command as part of the changes to add named pipes. They are, in fact, in the S5"R1" "mknod", which antedates NFS by several years, so they clearly have nothing whatsoever to do with NFS.
duncan@comp.vuw.ac.nz (Duncan McEwan) (09/07/88)
In article <66897@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> On all SunOS that I have access to (3.2, 3.5, 4.0) I got this when I try. >> >> mknod: must be super-user >> >> So it is a NFS problem. > >The only line of reasoning that I can see ... is "Sun invented NFS, so if it >happens on all versions of SunOS it must be an NFS problem". However, this >is one of the silliest lines of reasoning I have ever had the misfortune to >encounter ... Any other line of reasoning, however, is likely to be equally >silly The way I interpreted the comment that Guy is responding to was, "on all versions of SunOS without NFS, mknod does not have a problem, and since (as desribed in a previous article) there is a problem with mknod on systems with NFS, it is an NFS problem". Given this interpretation the reasoning doesn't seem so silly. For those that missed the posting describing the actual problem, it showed how root on a workstation with NFS is able to gain read/write access to the memory (and presumably using the same mechanism, the disk partitions?) of an NFS server. This seems to be more serious than the well known "root on a workstation can easily access any other (non root) users files on a server" problem. One partial solution to both of these problem for machines that can be accessed by people you don't trust, is to make it harder to become root on those machines. I think SunOS 4.0 can be configured to require the superuser password before coming up in single user mode. Of course, there may be many other ways of becomming root on the workstation that this doesn't protect against, but at least it blocks off one of the easiest. Do any other workstation vendors provide this protection? My only information regarding this feature in SunOS 4.0 is a brief mention in the 4.0 release notes, so I may have mis-interpreted it. No doubt someone will correct me if I have. Duncan
guy@gorodish.Sun.COM (Guy Harris) (09/08/88)
> The way I interpreted the comment that Guy is responding to was, "on > all versions of SunOS without NFS, mknod does not have a problem, and > since (as desribed in a previous article) there is a problem with > mknod on systems with NFS, it is an NFS problem". Given this > interpretation the reasoning doesn't seem so silly. Considering he didn't try it on any 1.x releases, and therefore didn't try it on any versions without NFS, it is difficult to see how the comment could be interpreted in that fashion. (In fact, he didn't try it on 3.0; 3.0 *did* have NFS, but I suspect it didn't have this problem, because I don't think it allowed "mknod"s over the wire.) Furthermore, the problem occurs when you succeed in doing a "mknod" system call, and you can only do so when you are running as root; he didn't try running "mknod" as root, because the message in question only comes out when you're *not* root. The message from the "mknod" command has nothing to do with any attempt to close the security hole in question: 1) putting a check into the "mknod" command doesn't close the hole, it only narrows it slightly, since anybody who can build a program at all (i.e., has access to the requisite tools and knows enough e.g. C) can build a program that calls "mknod" and 2) the check in the "mknod" command merely duplicates the check performed by the "mknod" system call, for reasons unknown to me. The correct fix is to make UNIX NFS servers refuse to create special files other than FIFOs if the credentials *after* any UID mapping is performed don't say the user is root. The best way to do this on a kernel with the VFS mechanism would be to change the UFS or System V file system "create" vnode operation to check the credentials it's handed, and refuse to do the operation (returning EPERM) if they don't say the user is root. (The check in the "mknod" call itself could then be removed, as it would be redundant at best and incorrect at worst - somebody might actually not want to require a process to be running as super-user in order to make non-FIFO "mknod"s on their particular file system type.) I've submitted a bug report on this. > My only information regarding this feature in SunOS 4.0 is a brief > mention in the 4.0 release notes, so I may have mis-interpreted it. > No doubt someone will correct me if I have. No, it should be correct; if you do not specify that "/dev/console" is "secure" in "/etc/ttytab", it should require you to give a password before going single-user. (I haven't tried it, so I don't know whether there are any problems.)
madd@bu-cs.BU.EDU (Jim Frost) (09/09/88)
In article <66897@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: |> On all SunOS that I have access to (3.2, 3.5, 4.0) I got this when I try. |> |> mknod: must be super-user |> |> So it is a NFS problem. | |since the |reason the "mknod" command prints that message is that it contains the lines | | if(getuid()) { | fprintf(stderr, "mknod: must be super-user\n"); | exit(2); | } | |which certainly have nothing whatsoever to do with NFS. In fact, those lines |came from the System V "mknod", and were added when named pipes were added to |SunOS, because we picked up the S5R2 "mknod" command as part of the changes to |add named pipes. They are, in fact, in the S5"R1" "mknod", which antedates NFS |by several years, so they clearly have nothing whatsoever to do with NFS. You're correct in that the error has nothing to do with NFS, but mknod will not allow anyone but the superuser to create files *at the system call level*. Even if mknod(8) didn't have the check you describe, the call would fail later in the program when mknod(2) was issued. [Note that the mknod system call can be invoked by non-superusers only for the creation of FIFO special files.] Another thing to be wary of is "superuserness" does not carry over NFS connections, thus if you were root on the local system and tried to issue mknod for a NFS filesystem, you might get the same style of error. This would, in fact, be a problem with NFS. But most people I know call it a feature. jim frost adt!madd@bu-it.bu.edu
guy@gorodish.Sun.COM (Guy Harris) (09/09/88)
> You're correct in that the error has nothing to do with NFS, but mknod > will not allow anyone but the superuser to create files *at the system > call level*. Even if mknod(8) didn't have the check you describe, the > call would fail later in the program when mknod(2) was issued. Yes, I'm quite aware of that; that's why I stated that I had no idea what the check was doing in the "mknod" command. The only effects the check in the command has are: 1) since the check is done before the check for "argc != 5" in the S5 version if a non-superuser forgets what the syntax is for creating FIFOs, they can't just type "mknod" and get a usage message (this is done right in the Sun version). 2) the error message you get if you're not super-user is mknod: must be super-user rather than mknod: Not owner which is a more useful message. This is the only reason I can see for sticking the check in. (The "correct" fix for this would be to add a new error code, so that you can distinguish between "you can't do that to the object in question because your effective user ID is not that of the owner of the object nor is it superuser", which would give the message "Not owner", and "you can't do that because you're not superuser", which would give the message "Not super-user". The two are distinct errors, but unfortunately are both reported with the same error code EPERM. It is, alas, a bit late to fix UNIX's overloaded error codes....) > Another thing to be wary of is "superuserness" does not carry over NFS > connections, thus if you were root on the local system and tried to > issue mknod for a NFS filesystem, you might get the same style of > error. This would, in fact, be a problem with NFS. But most people I > know call it a feature. The problem, as originally stated, is that the superuserness is irrelevant once the operation goes over the wire, in most UNIX NFS servers; the server does not forbid remote "mknod"s, even if 0 is mapped to -2. The check is done at the system call level, so neither the NFS server code nor the underlying UNIX file system code that the server calls does the check. The check should be done in the underlying file system code, and not at the system call level (after all, somebody might want to implement a file system on which non-superusers *can* do arbitrary "mknod" operations).
sjs@jcricket.ctt.bellcore.com (Stan Switzer) (09/13/88)
This discussion has pretty much ignored NFS using DES authentication. I must admit that I only gave the protocol spec a cursory reading, but the approach looks quite sound to me. Furthermore, this security mechanism is available to other services besides NFS. Does anyone who has looked at this system carefully care to comment? Stan Switzer sjs@ctt.bellcore.com
jfc@athena.mit.edu (John F Carr) (09/14/88)
In article <1487@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Just how heavy a load (in CPU power, throughput, and un-unix-like behaviour) >does the system used by Project Athena impose? First, a description of the system he refers to: The Kerberos authentication system is designed for use in an insecure environment. The fundamental assumption is that no machine needs to trust any machine other than a single server. In addition, there is a site requirement that any Athena user be able to login on any of the several hundred workstations (except those reserved for individual use). .rhosts and duplicate /etc/passwd on all machines are acceptable for a limited number of secure machines, but fail on large networks (consider the size of the passwd file for 6000+ users...then think of chaning it on each of 500 machines every time a user changes his password or a new user is added). One problem is solved by having a common, central database to store such information as: /etc/passwd entries for all users group lists location of NFS home directory location of mail server The other problem, authentication, is solved with Kerberos. There are a number of services for which authentication is desired, including: NFS uid mapping receiving mail sending certain types of messages access to the local equivalent of news Each service shares a private key with the kerberos server. A user gets a "ticket" to use that service from Kerberos; this is encrypted using the service key and the user's key (the user first decrpyts the ticket with his key, then sends it to the server); if the server can decrypt it then it can ID the user (since only Kerberos can encrypt with the service key). The exact sequence of encryption and details of message format are more complicated than I describe here. It is possible for root on a machine to steal tickets out of the file (mode rw-------) in which they are stored, but it is in principle possible for root to read a user's files in UNIX regardless of any security. The performance impact: Programs which require authentication have been re-written to use kerberos without any change in the user interface (an initial ticket is obtained at login and used to get more as needed). As long as the ticket has not expired, the change is invisible. Where possible, unauthenticated versions are kept as fallbacks (so, a failed kerberos rlogin tries again with the standard rlogin). CPU time is a consideration, since encryption is required. In the present implementation, most net traffic after the initial authentication is not encrypted, so there is almost no performance impact. I don't know how important it is for other applications (such as encrypted rlogin). That it works on such a large network is evidence that it does not require too much time (else the server would overload). For NFS use, there is an option to require authentication for all mounts (and restrict access to a specific list), or to map unauthenticated users to nobody. --John Carr John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, Will they read of us with sadness For the seeds that we let grow?" --Neil Peart
allbery@ncoast.UUCP (Brandon S. Allbery) (09/15/88)
As quoted from <14186@comp.vuw.ac.nz> by duncan@comp.vuw.ac.nz (Duncan McEwan): +--------------- | One partial solution to both of these problem for machines that can be | accessed by people you don't trust, is to make it harder to become root | on those machines. I think SunOS 4.0 can be configured to require the | superuser password before coming up in single user mode. Of course, | there may be many other ways of becomming root on the workstation that | this doesn't protect against, but at least it blocks off one of the | easiest. Do any other workstation vendors provide this protection? +--------------- Xenix has done this for years; which may become relevant with the advent of an RFS version of Xenix (and maybe an NFS version will be in the works; we'll have to see which one becomes dominant). System V can be configured with a line "initdefault:2:" in /etc/inittab which forces it to come up directly into multi-user mode (RFS-ites may want "initdefault:3:" instead). If this is done the only way to get into single- user mode is to log in as root and do a "telinit s". ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc "Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI
dpl@cisunx.UUCP (David P. Lithgow) (12/07/88)
-----------
To all networking afficionados,
I'm looking for information/scripts/code on determining the
level of security of Ultrix and other BSD-compatible systems vis-a-vis
NFS access. I'm hoping that something is out there which would assist in
keeping this system secure against intrusion and also be a tool for new
Sun workstations coming online - to make sure that the new system
administrator has secured the appropriate partitions in /etc/exports, among
other things..
Is /etc/exports the only nfs security mechanism between the
world and the workstation user?
If you have any references, or experiences, please pass them
along, and I will summarize interesting results back to the net.
--
David P. Lithgow Sr. Systems Analy./Pgmr., Univ. of Pittsburgh
USENET: {allegra,bellcore,ihpn4!cadre,decvax!idis,psuvax1}!pitt!cisunx!dpl
CCnet(DECnet): CISVM{S123}::DPL BITnet(Jnet): DPL@PITTVMShoney@mailrus.cc.umich.edu (peter honeyman) (12/07/88)
... and other oxymorons. followup to rec.humor. peter
jordan@zooks.ads.com (Jordan Hayes) (12/08/88)
peter honeyman <honey@citi.umich.edu> writes:
... and other oxymorons.
not necessarily. certainly things along the lines of using kerberos
for the authentication and fixing your mountd and running fsirand,
etc. go a long way toward cleaning up the nfs act on a unix box. as
to *how* to do this, or (better) to make the stuff from sun out of the
box do this, send followups to sun!sunbugs and comp.protocols.nfs ...
/jordan