NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS

[Manolis Kiagias]

Lowell Gilbert wrote:
> Manolis Kiagias <sonicy at otenet.gr> writes:
>
>   
>> I've read this the first time I tried and decided not to go with it.
>> The manual says:
>> "If you plan to use a FreeBSD system to serve non-FreeBSD
>> clients that have no support for password shadowing (which is
>> most of them), you will have to disable the password shadowing
>> entirely by uncommenting the UNSECURE=True entry in
>>  /var/yp/Makefile."
>>
>> Linux certainly uses password shadowing, and I can see in my debian
>> server maps passwd.byname and shadow.byname files
>> If I perform ypcat passwd.byname from a client I get the standard passwd
>> file with no passwords (exactly like /etc/passwd)
>> The encrypted passwords are in the shadow.byname map.
>>
>> Now, if I understand correctly, the above solution would put the
>> passwords in the passwd.byname map, thus making the system less secure,
>> where in fact I should be able to make FreeBSD export a shadow.byname
>> map that would be compatible with Linux.
>> Am I missing something here / are my assumptions wrong?
>>     
>
> I think you are assuming that Linux uses password shadowing over NIS.
> This is not possible, and no system does it.
>
> The FreeBSD security method in question just forces requests for the
> password maps to come from privileged ports.  This is a very minor
> security method, and other systems don't support it.
>
> Fundamentally, NIS assumes that you trust the machines you are
> serving.  Or at least are willing to let them have the encrypted
> passwords.  No OS can change this; it's not a Linux/FreeBSD issue.  
>
>
>   
I have experimented a bit further with my debian NIS server, and this is
what I found:

>From a NIS client, I can do with my standard user account:

sonic at atlantis:~$ ypcat passwd.byname
user1:x:1010:1010:Joe User,,,:/home/user1:/bin/bash

and I get the standard, world-readable password file (the one without
the passwords)
However, the standard user cannot run:

This is the answer:
sonic at atlantis:~$ ypcat shadow.byname
No such map shadow.byname. Reason: No such map in server's domain

As root, however:
root at atlantis:~# ypcat shadow.byname
user1:$1$1233245435435345543545345sfsdfsfdf:13577:0:99999:7:::
...

This seems to be consistent with the FreeBSD NIS Server behaviour
described in nis(8) manual page:

" To help prevent this, FreeBSD's NIS server handles the shadow password
     maps (master.passwd.byname and master.passwd.byuid) in a special
way: the
     server will only provide access to these maps in response to requests
     that originate on privileged ports.  Since only the super-user is
allowed
     to bind to a privileged port, the server assumes that all such requests
     come from privileged users.  All other requests are denied:
requests from
     non-privileged ports will receive only an error code from the server."

So, it seems linux handles this the same way. Difference is linux has a
shadow.byname map while FreeBSD has a master.passwd.byname map
(possibly  also internal differences in the files)

Now, if I understand correctly, If I where to add the UNSECURE feature
in the FreeBSD server, I expect the shadow passwords would be inserted
in the passwd.byname map which is world readable and hence a security
issue. (Perhaps I will do this experiment next and let you know of the
outcome)
This is hardly important for my home server scenario, but it would be, 
should I decide to implement a FreeBSD NIS server somewhere else.
Hence,  the best possible solution would be to get a Makefile for the
FreeBSD NIS server that would produce completely Linux compatible maps.