Re: NFS export to netgroup with duplicate hosts
Hi, Of course you are right. Netgroup support got in some area broken when I did the IPv6 merge of NetBSD code. It will be fixed soon, sorry ! Another issue with mountd is, that it allows still one set of flags for one mountpoint. This is done per radix entry in the kernel and tied to each file-system mount point. If we manage it, mountd should soon be able to allow different mount flags for each path you export in /etc/exports. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
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. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
* Martin Blapp [EMAIL PROTECTED] [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: "A, you are correct, now get cracking!"
s: ...
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
Le 2001-04-12, Alfred Perlstein crivait : 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?" The kernel could include a 'signature' in the handle, e.g. in the form of a hash of (perm-bytes,handle-bytes,secret-key). (But the following still holds:) s: "Master, this sounds like hella work!" (plus some crypto algorithm right in kernel space...) m: "A, you are correct, now get cracking!" Thomas. -- Thomas Quinot ** Dpartement Informatique Rseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
:Hi, : :Of course you are right. Netgroup support got in some area broken :when I did the IPv6 merge of NetBSD code. It will be fixed :soon, sorry ! : :Another issue with mountd is, that it allows still one set of flags :for one mountpoint. This is done per radix entry in the kernel and tied :to each file-system mount point. : :If we manage it, mountd should soon be able to allow different mount flags :for each path you export in /etc/exports. : :Martin : :Martin Blapp, [EMAIL PROTECTED] You can't do that. You could manage different perms for different hosts (i.e. /usr is rw for host A and /usr is ro for host B), but you can't mix perms for subdirectories within a mount to the same host. The reason is that the file handles passed to nfsd could then be trivially faked to gain rw access on a ro-exported subdirectory. For example, if you export /usr read-only and /usr/local read-write, you can then construct an NFS request using /usr/local's mount point but with a file handle that represents a file in /usr, and then be able to write to that file. This is because the file handle representing file X will be almost identical no matter which mount point X is accessed relative to. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS export to netgroup with duplicate hosts
The reason is that the file handles passed to nfsd could then be trivially faked to gain rw access on a ro-exported subdirectory. For example, if you export /usr read-only and /usr/local read-write, you can then construct an NFS request using /usr/local's mount point but with a file handle that represents a file in /usr, and then be able to write to that file. This is because the file handle representing file X will be almost identical no matter which mount point X is accessed relative to. Yes I see. I'd also like to see what happens if you move some directory, or if you are doing hardlinks and also move them ... :-) Your explanation is logical to me. Maybe we should fix the exports(5) manpage. This is not a bug, it's a security restriction. It seems to me that we have a really good nfs implementation here on BSD, and we can do more finetuning than on Solaris itself. Also mountd and export seems to support more features than in Solaris, according to the manpage. Could this export restriction change in future with nfsv4, when nfs does get stateful (I've heard about that the stateless behaviour will go away with nfsdv4) ... ? I do not know much about the internals of nfsv4 ... Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
