home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.bsd
- Path: sparky!uunet!cs.utexas.edu!wotan.compaq.com!moxie!hackney
- From: hackney@moxie.hou.tx.us (Greg Hackney)
- Subject: Re: 386BSD - Bug in UFS file system + proposed fix
- Message-ID: <1992Dec17.140123.9952@moxie.hou.tx.us>
- Organization: Home
- References: <1992Dec16.012248.8123@moxie.hou.tx.us> <1992Dec16.211422.3663@fcom.cc.utah.edu>
- Date: Thu, 17 Dec 1992 14:01:23 GMT
- Lines: 37
-
- terry@cs.weber.edu (A Wizard of Earth C) writes:
-
- > This fix seems a bad thing.
-
- The fix we proposed for ufs_vnops.c, is identical to 386BSD's sister code
- residing in nfs_vnops.c. I'm not sure why ufs_vnops.c got changed to
- something different.
-
- > In particular, you *don't* want to allow a
- > file which is world read or world execute to be read/executed by someone
- > who is a member of a group denied access.
-
- Did you try the code? On my system, group denied access works properly.
-
- > Perhaps the reason you are having NFS problems is because unknown users
- > and root users from a remote system are translate to UID -1 and -2 unless
- > you specify that root access is allowed on the remote machine in the
- > /etc/exports file
-
- Nope. The 2 systems are identical stock 386BSD systems with identical
- password files. We've tried /etc/exports with and without root=0.
-
- > (your example seems to indicate you were logged in as
- > root when you tried this).
-
- Nope. We've tried all sorts of logins.
-
- >Admittedly, there are some permission comparison problems, but these are
- >pretty well isolated, and will probably be more tha a one or two line fix.
-
- If no one else is having these (major) permissions problems when
- using NFS across 2 386BSD systems, then we need to go back and dig
- deeper into why the modes aren't working. Are you saying that it works
- properly for you?
- --
- Greg Hackney
-
-