On Fri, 12 Dec 2014, Mark Brown wrote:
On Fri, Dec 12, 2014 at 07:07:07AM -0500, Jon Daley wrote:
On Fri, 12 Dec 2014, Goswin von Brederlow wrote:
As I posted in the original report, there was a change to crypt() which now
exposes a long standing bug in nis.
OK, so this is new information. The original report said that perhaps
this was better fixed in crypt() (which may well be the case) but didn't
say anything about the behaviour of crypt() having ever been different,
based on the report it looks like this is something that's always
happened and has only just been noticed (which is entirely reasonable
since the use of shadow passwords with NIS is pretty unusual).
You are right that I didn't say that in the original report. The other
reporter apparently has used NIS longer than I have, so can more
confidently make that claim than I can.
You've made a couple references to using shadow and nis being unusual. Do
people usually turn off shadow passwords when using other systems? And
you also implied that NIS's lack of security makes shadow passwords
irrelevant. When I first installed NIS, I thought it might be exposing
the password file somehow, but I couldn't make it do that, and I get
permission denied errors when I try to see the actual password hashes from
a client. Can you give me a command that does?
It's not clear to me that this is something that has been newly
introduced (as opposed to something people have always dealt with when
using NIS, the version mentioned is the one in wheezy) - using shadow
files with NIS is obviously a bit of a corner case given how meaningless
NIS makes the extra security they add. If it's something that's just
broken in this version and people would see regress on upgrades that's a
bit different.
Since shadow passwords are the default, the "corner case" affects every user
of nis, unless they disable shadow. I assume disabling shadow would fix it.
I suppose for people doing completely fresh NIS deployments rather than
using something more current like LDAP...
I've played with LDAP before, and I've never been able to get to
work properly, and NIS seemed to be any easier route, but yes, this is a
fresh (as of a couple years ago) install.
Can you define "malformed"? I used "reportbug" to report the bug, and it
looks fine to me.
The most obvious thing is that your lines are *way* longer than 80
characters (appears to be something like 140 characters), looking at the
patch itelf it's also in some weird format which looks like it's also
trying to move the file.
I see. I assume that is because reportbug uses pico or some sort of
simple editor that doesn't know about email syntax. My email client wraps
the lines, so I didn't notice that before.
The patch probably was done manually or at least, not intended to be
automatically merged, but since it is all of 15 characters, it doesn't
seem like that should be a reason to dismiss it. After this conversation,
I've thought maybe a better patch is to check the return value of crypt,
rather than checking the length of the supposed hashed password. I don't
know the code well enough to know which way is better, I can make
arguments for either.
In any case, I don't think an argument can be made that my patch breaks
anything for anyone, and it makes the package usable for some, so it seems
like we've been taking a lot of effort talking about it, rather than just
fixing it. But, I have a /usr/local/bin/yppasswd, so it doesn't really
matter to me.
--
Jon Daley
http://jon.limedaley.com
~~
A good listener is not only popular everywhere,
but after a while he gets to know something.
-- Wilson Mizner
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
