On Fri, Dec 12, 2014 at 12:10:10AM +0000, Mark Brown wrote:
> On Thu, Dec 11, 2014 at 08:00:28PM +0100, Goswin von Brederlow wrote:
> > On Tue, Dec 09, 2014 at 03:34:43PM +0000, Mark Brown wrote:
>
> > > Please don't inflate severities pointlessly; there are simple solutions
> > > to this like changing passwords by logging into a specific system to do
> > > so which people will doubtless have adopted in the decade or so this has
> > > been present if they are affected.
>
> > 1) What system? The segfault always happens on every system. You simply
> > can not change your nis password at all.
>
> 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.
Trying to change the password on the server just gives:
# passwd test
passwd: Authentication token manipulation error
passwd: password unchanged
And normal users aren't allowed to login on the server in any case.
yppasswd is the only way to change a users password here.
> > 2) And it hasn't been a decade. It was reported a bit over a year ago.
>
> > 3) I first noticed this failing on Ubuntu recently while the nis
> > upstream version is indeed been around for ages. It used to work
> > previously with near identical version. So unless you changed
> > yppasswd.c in one of the debian revisions this probably is triggered
> > by a change in the crypt() implementation that is more recent, one
> > that validates the salt properly.
>
> 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.
> > 4 ) This is a security issue so raising the severity is not pointless.
> > Users need to be able to change their password. Especially the initial
> > one set by the admin on account creation.
>
> 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.
It is a regression on upgrade. As said above I think it is a change in
the crypt function that now exposes the bug in nis. Probably been
there for decades but now crypt returns NULL for a 1 character salt.
> I could probably go for important but given both the failure mode and
> the fact that it looks like this was an issue on the prior release it
> seems it does more harm than good to remove the package.
Think about the usual use case of nis. You have a number of systems
with an admin staff and a ton of users. Admins create new users, usualy
with some dummy password, and users are supposed to change it when they
first login. Now they can't anymore and are stuck with the dummy
password. At university I had accounts with user: algo17, pass:
algo17. Guess what user/pass the person to my left and right had.
> > 5) There has been a trivial 1 line patch for the bug for the whole
> > time.
>
> 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).
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
