Date: Tue, 9 Oct 2001 11:45:18 +0200 (MEST) From: Peter Cornelius <pcc@gmx.net> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: freebsd-questions@freebsd.org Subject: Re: Another one chokes with /etc/exports ... Message-ID: <8932.1002620718@www8.gmx.net> References: <200110071905.aa52971@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a MIME encapsulated multipart message - please use a MIME-compliant e-mail program to open it. Dies ist eine mehrteilige Nachricht im MIME-Format - bitte verwenden Sie zum Lesen ein MIME-konformes Mailprogramm. --========GMXBoundary89321002620718 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Re... > In message <20011007102827.A7475@akk3.akk.org>, Peter Cornelius writes: > > > >... I seem to continiously trick myself trying to rewrite my > /etc/exports. [...snip...] > Much of the problem with /etc/exports is that the syntax gives the > impression that you can have much more fine-grained control over > exports than is actually possible. I think this is the wooden track that I was on. I currently use -alldirs but would like to have a different mechanism. On the other hand, since there's a firewall towards the outside and I should consider my machines at least 'trustworthy' I will probably keep things this way until I have a better idea. > NFS access control essentially consists of one rule per local > filesystem, per remote host. Once any part of a local filesystem > is exported to a particular remote host, that remote host effectively > has access to the whole local filesystem, even if you only allow > mounting from particular nodes within the filesystem. Access is of > course restricted by -ro/-maproot/-mapall settings too. So if /usr > is a single filesystem and you have an entry in /etc/exports that > reads > > /usr/home /usr/foo/bar /usr/foo2/bar1 host1 > > then from a security point of view, you might as well have: > > /usr -alldirs host1 > > Specifying a list of nodes within a single filesystem limits what > directories can be used in a mount operation on the remote host, > but the remote host could still get the filehandle for /usr/foo/bar > and repeatedly look up ".." to get to the root of the exported > filesystem (you need a special nfs client to do this). [...snip...] This basically is what I thought (feared) from what I've seen. > If you want tighter access control, you will need to split up /usr > into different filesystems. That is unfortunately just the way NFS > works. It might be possible to implement a system that virtualises > the view of the filesystem exported to the remote client to "fix" > this, but doing this would be quite a lot of work. > > (NFS requests from the client contain a filehandle that specifies > which file is being accessed. From the filehandle, the NFS server > code extracts a filesystem and an inode. It checks if the sender > of the request is allowed to perform the requested operation on > the filesystem specified by the filehandle, and if so it does it. > There is no mechanism in place that could determine whether the > client is allowed access to a particular inode; the NFS server in > the kernel isn't even told what directories in a filesystem are > exported, and even if it was, checking that an inode is within an > allowed directory is not easy). Thanks a lot Ian, this makes it a lot clearer (and easier to remember for me, too). One will probably only get finer granularity if we'd have acls like some other os have and only if we wished to do the effort. I now (well, as soon as everything's up again which could be some time) will investigate other file sharing and authenticating mechanisms that are offered for FreeBSD; I think there are also some interesting things in the ports. But I'm afraid that this will take quite some learning on my side... Well, we'll see. Anyways, thank you very much indeed for elaborating to such detail on the subject which I understand by the sheer number of times that it has come up might bore some people. Thank you. Best regards to everyone reading here... cheers, Peter. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net --========GMXBoundary89321002620718 Content-Type: application/octet-stream; name=" " Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=" " --========GMXBoundary89321002620718-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8932.1002620718>