On Fri, Dec 12, 2014 at 07:07:07AM -0500, Jon Daley wrote:
> On Fri, 12 Dec 2014, Goswin von Brederlow wrote:
> >>The normal thing I've seen is to have people log onto the master server
> >>(or make some similar arrangement) and make the change there.

> >I think you can have a setup where nis exports the /etc/passwd of one
> >master server or something. But at least that isn't the setup we use.

Right, so you'd need one of the "or make some similar arrangement
cases".

> >>There's definitely not been any substantial change in nis for some
> >>considerable time, the last non-packaging change I'm seeing in the
> >>changelog is about five years old and is in wheezy.

> >But that's the thing. yppasswd works fine in wheezy and precise but
> >segfaults in jessie and trusty.

> 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).

> >>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...

> >>Right, it's unfortunate that I didn't see that on the original filing
> >>(looking at the mail it appears it got hidden as a signature by the
> >>mail client I used to read the original submission, the mail is sadly a
> >>bit malformed which doesn't help).

> 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.

Attachment: signature.asc
Description: Digital signature

Reply via email to