eric@ms.uky.edu (Eric Herrin) (09/04/87)
I have a rather unique(?) problem here running RFS over a STARLAN network of AT&T 3b2s. Root cannot be equivalent over all the machines. This tends to break many of the SUID root programs which use shared files and directories, since root has no special access to things like a user's directories which reside on other machines. Limiting ROOT access to foreign machines is a nice security feature, mostly for sites in which several groups of people own different sets of machines on the network (ie. it is usually not desired for someone's workstation to be equivalent). I really don't care about such situations, simply because they do not exist here. I am the only System Admin. of the RFS. My solution was to hack the DU module so it allows root equivalence. I am not sure if other people have experienced similar problems or even if anyone else actually runs RFS. If anyone has needed to allow root equivalence, and has a better solution, I would love to hear about it. Otherwise, I am willing to talk about my solution to any interested parties. eric | | | Eric Herrin II cbosgd!ukma!eric | | "'tis better to be silent eric@UKMA.BITNET | | and be THOUGHT a fool, than to open eric@ms.uky.csnet | | one's mouth and remove all doubt." eric@ms.uky.edu |
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/04/87)
In article <7211@e.ms.uky.edu> eric@ms.uky.edu (Eric Herrin) writes: >My solution was to hack the DU module so it allows root equivalence. I thought you could achieve this with existing facilities (e.g. the rules files used by idload(1M))? What am I missing?
ekrell@hector..UUCP (Eduardo Krell) (09/05/87)
Have you tried
global
default transparent
in your /usr/nserve/auth.info/uid.rules?. This works for us. We're not
running RFS over STARLAN, but that should make no difference.
By the way, we're running SVR3.1
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrelleric@ms.uky.edu (Eric Herrin) (09/05/87)
>Have you tried > >global >default transparent > >in your /usr/nserve/auth.info/uid.rules?. This works for us. We're not >running RFS over STARLAN, but that should make no difference. >By the way, we're running SVR3.1 > > Eduardo Krell AT&T Bell Laboratories, Murray Hill > > {ihnp4,seismo,ucbvax}!ulysses!ekrell This seems to work just fine for every uid except root.. This was, of course, the very first thing I tried. I tried rebooting RFS, the OS, and resorted to the hack as a last hope (at least I knew it would work). The uid.rules and gid.rules SHOULD do what you have implied, and if they actually do for you, maybe there is something else wrong. I am running SVR3.1 (with sources of course) with ether and starlan, but only starlan with RFS. The uid being returned from the server side when root owns something is NO_ACCESS or MAXUID+2. This implied to me that the .rules files were automatically excluding root. If you have any further suggestions, please e-mail me unless there is considerable interest on the net about this. eric
mjp@sfmag.UUCP (M.J.Purdome) (09/08/87)
> In article <7211@e.ms.uky.edu> eric@ms.uky.edu (Eric Herrin) writes: > >My solution was to hack the DU module so it allows root equivalence. > > I thought you could achieve this with existing facilities (e.g. the > rules files used by idload(1M))? What am I missing? Right. The ID mapping rules files used by idload allow all sorts of mapping between users. I think the typical default configuration has files that say something like global default transparent exclude 0-99 which allows all users to be mapped except 0-99 (the administrative logins), which become MAXUID+1. If you delete the last line, all users, including root, are mapped transparently. Check the rules files, located in /usr/nserve/auth.info/?id.rules, the man page for idload(1M), or the _Administrator's Guide_, which has an RFS tutorial. -- Mark Purdome AT&T UNIX System Development Laboratory 190 River Road A-130, Summit, NJ 07901 {ihnp4,allegra}!attunix!mjp disclaimer: these statements do not represent AT&T policies or opinions