Date: Thu, 12 Apr 2001 11:00:22 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Martin Blapp <mb@imp.ch> Cc: Thomas Quinot <quinot@inf.enst.fr>, current@FreeBSD.ORG Subject: Re: NFS export to netgroup with duplicate hosts Message-ID: <20010412110021.D24582@fw.wintelcom.net> In-Reply-To: <Pine.SGI.4.10.10104121836360.3093471-100000@harem.imp.ch>; from mb@imp.ch on Thu, Apr 12, 2001 at 07:10:38PM %2B0200 References: <20010412182900.B30764@cuivre.fr.eu.org> <Pine.SGI.4.10.10104121836360.3093471-100000@harem.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
* Martin Blapp <mb@imp.ch> [010412 10:11] wrote:
>
> > If we manage it, mountd should soon be able to allow different mount flags
> > for each path you export in /etc/exports.
>
> I'm sorry. But now after some investigations and talks with Robert
> Watson it seems to be clear that this is not possible due the way nfs
> works.
>
> It would be easy to fix mountd, and to store somewhere the path where
> the export is tied to, but how should nfsd handle this ? He get's a
> request for a inode (the namei translation is done on the client side).
> The server has now to look which flag set belongs the inode. How can he
> see which set of flags belongs to that inode ?
>
> man share_nfs on solaris 7:
>
> Unlike previous implementations of share_nfs(1M), access
> checking for the window=, rw, ro, rw=, and ro= options is
> done per NFS request, instead of per mount request.
>
> In suns implementation of nfs is written (man share)
>
> If share commands are invoked multiple times on the same
> filesystem, the last share invocation supersedes the
> previous-the options set by the last share command replace
> the old options. For example, if read-write permission was
> given to usera on /somefs, then to give read-write permis-
> sion also to userb on /somefs:
>
> That means that it's not possible as I get it. I'll do further
> investigations to be sure how it works on Solaris exactly.
It's actually relatively trivial to "implement". The reason I
say "implement" is because it's fake when done unless you keep
a contiguous parent mapping of all files being accessed through
NFS.
You simply encode the perms in the NFS filehandle then hang that
in the exports list.
Let's take a v2 filehandle:
struct nfs_fh {
opaque data[NFS_FHSIZE];
};
This is 32 bytes.
Let's encode the "mount point" in the top byte.
Ok, now what we have to do is reply to each request with the same top
byte to indicate that it came from the same mount point.
In the export lists hung off the mount point we now have a
data structure that looks like this:
{ client_addr, magic_perm_byte, perms }
So now, you just search until you match {client_addr, magic_perm_byte}
then check {perms} for access.
...
student: "Ok master we have multiple export types with different
permissions!"
master: "Well, actually grasshopper we've just introduced a security
hole for the uninitiated."
s: "How can this be???"
m: "What if the administrator was to grant a non trusted client
read-only access to a share, then at a later date give the same
non trusted client write access to another share on the same
paritition?"
s: "I'm not following you dude."
m: "Don't call me dude." *thwack* "The point is that if the
workstation is untrusted, what's the stop the mallicious hacker
from taking a read-only filehandle and swapping the top byte with
the byte required for write access?"
s: "Well, why not make sure it's a valid handle for that mountpoint?"
m: "That's where it gets tricky, you see, then you need to keep a
cache of root nodes, meaning the mount points exported by mountd
in the kernel, as well as cache each opened item attaching the
{magic_perm_byte} to it along with {client_addr}, since NFS is
stateless we really never know when it's safe to retire these cached
filehandles, but let's just LRU them and return ESTALE when a
filehandle not in the cache comes in"
s: "Master, this sounds like hella work!"
m: "Ahhhh, you are correct, now get cracking!"
s: ...
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010412110021.D24582>