NIS interoperability with Linux, was Re: Following directions
doesn't seem to work: Adding users in NIS
sonicy at otenet.gr
Thu Oct 18 08:18:54 PDT 2007
Lowell Gilbert wrote:
> Manolis Kiagias <sonicy at otenet.gr> writes:
>> 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
>> 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
>> 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
>> 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.
> Hmm. What you're saying makes sense; unfortunately, I haven't had a
> network configured this way in a while, so I'm rather rusty on the
> details. It sounds as though this is just a matter of the map names.
> Perhaps you could handle that with nicknames?
It is a matter of names, but also there are changes internally in the
file. All can be handled by a modified Makefile, which I hope to be able
I have a few more urgent "experiments" with the test machine, so this
will have to wait for a while.
> I believe that the master.passwd.byname map is in the same FreeBSD-
> specific format as master.passwd, but that on all systems
> passwd.byname is the standard old format that YP always used.
In fact, in Linux, shadow.byname is the exact same format as
/etc/shadow, so I believe your assumption about master.passwd.byname is
> In most (not all, but most) cases, I don't think it's worth worrying
> about the "secure" modes available, whether you're taking the FreeBSD
> or the Linux map names and formats. It's based on the assumption that
> someone untrusted can be on your network but can't use low-numbered
> TCP ports. This is unusual in my experience.
True, and as I said for my home network this is more of an "academic"
However considering the (probable) outcome of the UNSECURE line in
Makefile, it would reduce the security of a host to pre-shadow days. The
hashes would be available to anyone, and then someone could discover
john the ripper and give brute force a try. This is probably something
to keep in mind for more security-conscious environments. Combine it
with the fact it would affect all nis clients and not a single machine,
and you may get a serious security incident.
> Good luck.
Thanks, should I decide to "wrestle" with the Makefile, I will need it :)
More information about the freebsd-questions