Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5443 ; Thu, 24 Dec 92 09:00:28 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!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