Date: Sun, 29 Dec 2002 22:30:45 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Robert Watson <rwatson@freebsd.org> Cc: joe mcguckin <joe@via.net>, freebsd-hackers@freebsd.org Subject: Re: NFS & ACLS's ? Message-ID: <3E0FE815.653A4844@mindspring.com> References: <Pine.NEB.3.96L.1021229235134.80032B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Fri, 27 Dec 2002, joe mcguckin wrote: > > Are there any strange interactions between NFS and filesystems that are > > not UFS? E.g. UFS2? Does NFS support new features that these fs's may > > implement? > > NFS can represent many but not all of the services found in UFS1 and UFS2. > Among things it doesn't support are the retrieval and manipulation of BSD > file user flags, system flags, extended attributes, and access control > lists (ACLs). However, NFSv3 does correctly handle enforcement with these > features because clients rely on the server to evaluate protections on > file system objects using an ACCESS RPC. Participation in the enforcement protocol is, unfortunately, voluntary, however. 8-(. > NFS2 evaluates protections on > the client (if I recall correctly) so may not behave properly. s/may not/will not/ > There are > RPC extensions to NFSv3 to retrieve and manipulate ACLs on Solaris, IRIX, > et al, but we don't currently implement those extensions. Last I tried, they were not implemented identically on the various platforms, so I scrapped the idea as being bogus. Without a standard, code is useless. > Likewise, NFSv4 > supports ACL management, but we don't yet implement NFSv4. It shouldn't > be too hard to dig up information on the NFSv3 ACL RPC extensions and > implement them on FreeBSD 5, since the semantics of our ACLs are highly > compatible with Solaris and IRIX. They aren't identical, unforntunately. You can get close by passing one at a time, but it's not really worth it to do local enforcement. I'm actually not a fan of NFSv4. The biggest NFS problems that exist are timesync and locking, and it doesn't solve either one of those very well. I suggested to the RFC authors several times at the draft stage that they include a local timestamp on all operations, which would have eliminated the timesync problem (all times could be represented in responses as deltas from the system time minus the timesync). The only real project to implement, outside of commercial vendors, appears to be a university project on Linux, which from my reckoning is not going well (I greatly admire the CS department attempting the work, so I don't know why that's the case...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E0FE815.653A4844>