I wanted to know why my NIS+ space died when I removed read permission for
NIS+ group nobody from all the tables.
Martin Trampler <trampler@pi1.informatik.uni-mannheim.de> points out that
the answer lies in "man nis+" and adds additional analysis, appended
below.
Basically, various bootstrap processes start reading the cred table as
nobody before they authenticate ... removing read access kills their
ability to authenticate to NIS+ ... and bad things start happening.
I've rebuilt my NIS+ space and this time I've removed read permission for
group nobody from every table ... except for passwd (no effect, even if I
do) and cred. The NIS+ space is still alive, and I have achieved the
desired effect, namely that users without NIS+ credentials cannot telnet
or ftp *out* from the box.
--sk
Stuart Kendrick
Network Services
FHCRC
Original query:
I ran this command for the standard tables in the NIS+ space, e.g. foreach
x in (auto_home, auto_master, bootparams, cred, ethers, group, hosts,
mail_alaises, netgroup, netmasks, networks, passwd, protocols, rpc,
sendmailvars, services, timezone). As I understand it, this removes read
permission for unauthenticated NIS+ users (NIS+ group "nobody") on all
tables.
I thought I was taking a draconian step toward preventing unauthenticated
NIS+ users from poking around the box. I'm building a machine with a few
credentialed Unix admins and lots of users who only need access to the box
for mail, nothing else. I'm not planning to give any of the users NIS+
credentials. Removing read permission for group nobody on the services
table has the fascinating effect of preventing unauthenticated NIS+ users
from using network-related binaries, e.g. telnet or ftp. (e.g they can
telnet *to* the box but not away from it.)
The next time my daily "nisdump" shell script ran (dumps the tables to
files), I started seeing "no public key for unix.machine@domain", where
'machine' and 'domain' were appropriately specific.
I ignored this for a few day ..., until none of us could log in. Other
painful things were happening as well. At that point, I found that
nobody, not even root on the root master, could look at tables.
My interpretation: every single entity had lost its NIS+
credentials. Clearly,
this has detrimental effects on all sorts of things. Nobody, not even
root, had permission to touch the NIS+ space. I ended up ripping out NIS+
and reinstalling from scratch.
I repeated the process yesterday and today logged in and reversed the
process, e.g. "nischmod n+r x.org_dir" where I replaced x with each of the
seventeen standard table names. The decay process had not yet progressed
to the point where I or root on various machines had lost our NIS+
credentials; this series of nischmod commands went smoothly. I
checkpointed the logs and verified, via
"nisls -l" that each of the tables now had read permission set for group
nobody.
And the NIS+ space seems to be functioning in all the usual ways. Like, I
can log in everywhere. sendmail is continuing to resolve aliases.
pinging processes continue to resolve host names.
But I can't modify the cred table anymore.
bug1{root}: nisls -l cred.org_dir
T r---rmcdrmcdr--- bug1.fhcrc.org. Tue Feb 4 10:06:37 1997
cred.org_dir.fhcrc.org.
The permissions seem to be set correctly. Each machine has DES
credentials. Each of the members of the NIS+ admin group have both LOCAL
and DES credentials. But neither root nor members of the admin group can
modify the cred table. They can look but can't touch.
Can anyone flesh out this story for me? Why does removing read permission
for group nobody on the services table disable telnet, ftp, etc.? Why
does removing read permission for group nobody cause this slow and painful
death of the NIS+ space (specifically, I think all entities lose their
NIS+ credentials, not all at once, but gradually)? Is there a way for me
to fix this remaining cred table problem, short of nuking the NIS+ space
and rebuilding it from scratch?
The NIS+ domain consists of a root master, three root replics, and a
couple clients. Solaris 2.5.1 with the identical set of recent patches on
each box.
--sk
And the answer from Martin:
Hi Stuart,
>>>>> "SK" == Stuart Kendrick <sbk@fhcrc.org> writes:
SK> I ran this command for the standard tables in the NIS+ space,
SK> e.g. foreach x in (auto_home, auto_master, bootparams, cred,
SK> ethers, group, hosts, mail_alaises, netgroup, netmasks,
SK> networks, passwd, protocols, rpc, sendmailvars, services,
SK> timezone). As I understand it, this removes read permission
SK> for unauthenticated NIS+ users (NIS+ group "nobody") on all
SK> tables.
Well, actually all I can give you is an excerpt from the NIS+ Manpage:
-----------------------
Note that for bootstrapping reasons, directory objects that
are NIS+ domains, the org_dir subdirectory and the cred
table within that subdirectory must have read access to the
nobody principal. This makes navigation of the namespace
possible when a client is in the process of locating its
credentials. Granting this access does not allow the con-
tents of other tables within org_dir to be read (such as the
entries in the password table) unless the table itself gives
"real" access rights to the nobody principal.
-----------------------
Since I'm only a novice in the black magic of NIS+ I can't help you
much farther, but here are my 2cents (actually pfennigs) to your
questions:
1.) Why does removing read permission for group nobody on the services
table disable telnet, ftp, etc.?
It should do this only for users who lack nis+-credentials. These
programs make all kind of system-calls (getprotobyname, gethostbyname)
which depend on the tables in org_dir
2.) Why does removing read permission for group nobody cause this slow
and painful death of the NIS+ space
The secret key of nis+-principals is stored by a daemon (keyserv). It
stays there, even after the principal logged out. The cached value is
removed from the keyserv after an explicit "keylogout". I think (can't
verify it) that the key also expires from keyserv after a specific
amount of time if it's no longer used. If the principal needs to
regain his secret key (which is encrypted with his login-passwd and
stored in cred.org_dir) but cred.org_dir is not readable for him (who
-at this stage- has not authentification) he can't get his encrypted
key. (What I just wrote makes sense for "human" users. Workstations
have their decrypted private key stored in /etc/.rootkey, so from the
top of my head I can't tell why this should happen for Machines)
3.) Is there a way for me to fix this remaining cred table problem,
short of nuking the NIS+ space and rebuilding it from scratch?
>From here I can't tell. If I were you, I would (after having read the
Manpages and Answerbook-Entries) do some "niscat -o ...", nisls ...,
and nis... to get a better understanding of the problem. Have you
tried an explicit "keylogin" as member of the admin group ?
Sorry not to be able to solve your problem but maybe I could give you
some hints what to look for.
Cheers
Martin Trampler
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT