[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: perl or libc6 bug?: getpwnam('root') in NIS environment



Hi,

thanks for the lot of responses, I'll try to summarize it some way
and answer all mails with this one:

: > authenticator for squid and discovered the following:
: >
: >     #! /usr/bin/perl
: >     print((getpwnam('root'))[1], "\n"); 
             ^                           ^ sorry, added these parens ...
: > returns the root encrypted password from the NIS-Servers /etc/shadow ...!!

. This short script runs with joe user privileges.  
. It returns the encrypted password entry for root from the NIS server.  
. The NIS server has shadow passwords turned on.
. On the NIS client acting as slave is the same as on a `pure' NIS
  client.
. On the NIS server I get the expected `x' for shadow passwords.
. Shadow mangling is switched off

: Are you running this as root? If not then you have some other anomoly,
: since perl doesn't run with enough privs to read /etc/shadow (unless
: you have shadow passwords disabled, in which case there is no problem).

Shadow is on.  On the server as well as on the clients.  (I know, for
NIS there is not too much sense in doing this ...)

: Alternatively, do a 'ypmatch root passwd' and see if you get the
: hashed password.

`ypmatch root passwd' returns nothing, as expected for joe user.  

: remember that getpwnam() refers through /etc/nsswitch.conf first. If you've
: set "passwd: files nis", you can get a different result doing "print

Yes.  If running as joe, I get the above results (root hash from the NIS
server), if running as root, I get the root hash from the local host.

: privilege. (I certainly don't think it's a problem in perl, I imagine it's
: just returning results from getpwnam(3)...)

Yes, it returns just the `x'.

: have been a root process that did the request. That way the NIS
: server can see if a process is priviliged.
: 
: 2. You can decide wether or not to serve the shadow password file
:    based on the port number the request originated from.

Yes, with mangling ON it works like expected.  (But the
/etc/ypserv.conf should contain a line for the shadow.byname
map too.  Probably a wishlist item for the base files?)



To sum it up again:


With mangling OFF I get the shadow entry for root from the NIS server.
`ypmatch root passwd' returns `no such key' or similar
`ypmatch root shadow.byname' returns the approbiate line from the shadow
file ...

I can always lookup the shadow.byname map completly.  (Not so for
passwd!)


With mangling ON it's a little bit cleaner ... but not completly clean.
Why is the root (and other low uid) entry hidden from passwd.byname, but
not from shadow.byname?


    Best Regards from Dresden/Germany
    Viele Gruesse aus Dresden
    Heiko Schlittermann
-- 
[internet & unix support ----------------- Heiko Schlittermann]
[<a href="http://debian.schlittermann.de/";> Debian 2.1 CD </a>]
[Heiko Schlittermann HS12-RIPE finger:heiko@schlittermann.de -]
[pgp: A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 -------]


Reply to: