phil@hypatia.rice.edu (William LeFebvre) (05/19/89)
Now it wouldn't be all that unusual to want to export a given partition
as read-only to a whole bunch of machines and read-write to a small
number of machines, would it? Let's see how difficult Sun makes it for
us.
Let's say that I have two netgroups: cs and ee. I also have a file
system that I want all the cs machines to have read-write access to.
But, some people in the ee group also need access to it. Since they
only want to read from that partition, I'd like to set it up so they
can't mount it read/write. This just makes me feel like I have more
control over the systems I manage.
Well, a quick glance at exports(5) leads me to use the following entry:
/dir -ro,access=cs:ee,rw=cs
"Hey, wow," I say, "this exports stuff is pretty simple to use."
But woe is me when exportfs says "cs: unknown host." Closer scrutiny
of exports(5) unearths the obscure but important fact that netgroups
can *only* be used in the "access" option.
Just for kicks I tried two separate entries for the same file system.
As I suspected, it only paid attention to one of them.
So what this boils down to is that you can only specify one set of
netgroups per file system, and that entire set must have identical
mount privileges. This does not sit well with me. Not in the least.
And before some wise guy tells me that I can just list all the hosts I
need in the "rw=" option ("rw=a:b:c:d:...") let me say that, in our
case, there are almost 60 hosts in the cs netgroup, and it does change
from time to time. I am *not* going to do that!
I also see no provisions for wild-carding domain names, as in
"*.cs.rice.edu", which would be an interesting alternative to those
deprived of using netgroups.
So there really is no way to have different mounting privileges for
different netgroups. Maybe I'm weird, but I sure think that would be a
useful feature (and not particularly hard, either).
Gee, thanks Sun!
William LeFebvre
Sun-Spots moderator
Department of Computer Science
Rice University
<phil@Rice.edu>mende@athos.rutgers.edu (Bob Mende Pie) (05/24/89)
In article <4478.phil.hypatia@Rice> phil@hypatia.rice.edu (William LeFebvre) writes: > Now it wouldn't be all that unusual to want to export a given partition > as read-only to a whole bunch of machines and read-write to a small > number of machines, would it? Let's see how difficult Sun makes it for > us. > [....] > And before some wise guy tells me that I can just list all the hosts I > need in the "rw=" option ("rw=a:b:c:d:...") let me say that, in our > case, there are almost 60 hosts in the cs netgroup, and it does change > from time to time. I am *not* going to do that! Wouldn't it be funny if someone does... try exporting /dir -ro,rw=a:b:c:d:... this is what I did, and mounted /dir on my client specifying rw as an option. mount reports that it is mounted (rw). But when trying to write to the filesystem it gets a read-only-file-system error. Come on sun. Allow mounting of ancestors (eg: /var and /var/spool/mail) and allow two (or more) export conditions for each partition. My case I have a bunch of tek workstations that dont support domains (hostnames cant have "." in them) that try to mount a sun filesystem via nfs. With named returning a domainified name for them nfs mounting looses. So I want somthing like /dir -ro,rw=myclients where myclients is a netgroup. This should allow machines in myclients to mount rw, while everyone else can mount ro. Also... fix the mount command so it does not lie when reporting how it has mounted a filesystem. /Bob...
hedrick@geneva.rutgers.edu (Charles Hedrick) (06/10/89)
From: mende@athos.rutgers.edu (Bob Mende Pie) >So I want somthing like > /dir -ro,rw=myclients There's a good reason why Sun doesn't allow netgroups in the rw clause. Every time an RPC request comes in from a client, the kernel has to check whether it is from a machine that is permitted to have write access. I think Sun decided that having the kernel look a name up in the netgroups database would be a bit too much overhead to be done per packet. It's no problem with access=, because that only has to be checked once, at mount time. Of course one could cache the results of the lookup, so it might be practical to use a netgroup for rw=, but the code would certainly be more complex. There are enough problems in 4.0 already without adding more complexity. Actually, as it turns out, the systems Bob Mende is responsible have a different solution to the problem, but it's a local Rutgers hack. We allow /dir -rw,access=netgroup /dir:2 -ro that is, separate lines in /etc/export. If you are in the netgroup, you match the first line and get rw access. If not, you match the second and get ro access. The system gives the client different file handles at mount time, so there's no problem telling which kind of system requests comes from. However it's not entirely clear that our implementation of this concept is very secure.
phil@delta.eecs.nwu.edu (Bill LeFebvre) (06/22/89)
In article <3725@kalliope.rice.edu> gretzky@unison.larc.nasa.gov (Mr. Stanley Cup) writes: |Has anyone tried this: | | /dir -access=foes:friends,rw=friends | |with the same definitions as above? Just wondering. I don't have the need |for this *feature* yet :-) and lack the time to try. This won't work. That was the whole point of my article. The only option that takes netgroups for arguments is "access". "rw" expects the names listed there to be actual machine names. It doesn't even try to look them up in the netgroups database. This is what I find very annoying. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>