> >we have a secure nis map passwd.adjunct.byname and password files like this line
> >sithglan:##sithglan:31401:30003:Thomas Glanzmann, CIP Admin:/home/cip/adm/sithglan:/local/login/bin/env-csh
> >Now we have a problem ... we have some PAM applications which have to verify a
> >password and should not be set user id root ... but that does not work.
> >We compiled them with pam support. But they still need set user id root. What
> >can we do else?
> >Under Linux it works without the set user id sbit.
> Hmm I thought Linux implemented the same security action in their NIS
> client library long ago.
> The NIS server is requiring the client to have root priv's in order to
> protect the shadow password data from prying eyes. If anybody could
> access the passwd.adjunct.byname map there's no point in having shadow
> passwords it might as well be in the public passwd.byname map.
> It does this restriction by requiring the NIS client open a connection
> from a reserved port less than 1024 to connect to the NIS
> server. Since root is the only one that can open a reserved port root
> is the only one that can authenticate against the
> passwd.adjunct.byname map on Solaris (and I thought that Linux
> required this as well but perhaps that is a configuration option).
> I'm afraid your only option is to make the app setuid root on solaris
> in order to validate passwords. Some people have setup little password
> checking daemons to seperate out their apps from a small secure setuid
> daemon with a secure path between them (ie. the passwd.check stuff
> from the Cyrus SASL library comes to mind). Others just run as setuid
> root (ie. xscreensaver).
You didn't get the point.
Under Linux xlock works without sbit and with pam support from the same SUN NIS
Server. Under Solaris not, but why?
It seems that Linux pam library can open a port under 1024 to get the secure
map, but Solaris pam library can't, but why? Is there something special with
Linux pam support ... or just a configuration problem with Solaris.