Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Mon, 12 Mar 2007 16:48:16 -0500
schrieb Jeremy Blosser <jblosser-smgl AT firinn.org>: 

> On Mar 12, Jeremy Blosser [jblosser-smgl AT firinn.org] wrote:
> > On Mar 12, David Brown [dmlb2000 AT gmail.com] wrote:
> > > On 3/12/07, Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:
> > > > Spells that encountered problems:
> > > > ---------------------------------
> > > > shadow
> > > >
> > > 
> > > Yeah I saw the same thing on my box with this recent shadow update.  I
> > > had to compile it without pam support for it to succeed then things
> > > (like logging in) worked.
> > > 
> > > Haven't had time to mess with why or how if you remove the `>
> > > /dev/null 2>&1` part of the groupadd command in libaccount it spits
> > > something out about pam authentication failure.
> > 
> > Hrm then this may go back even farther than the commits I reverted, it
> > could be fallout from 1cacf5cbe4a6705b2c10b0a5a8e616965e12323f / bug 
> > 13600.
> 

> Wait, this makes sense: You can't groupadd from shadow's install during an
> upgrade; shadow is dispelled at that point and groupadd's auth chain is not
> going to work!

Heh? It's happening afer make install and after installing config files
(without castfs at least).
And casting works for me. Without PAM.
groupadd is there at this stage - be it in castfs or in real root (in
the INSTALL_ROOT case, it should still be in host system and there we
know that our account managing system won't actually create accounts in
$INSTALL_ROOT).
It even does spit out an error about PAM auth, so it is there.

> Nothing to do with the 13600 fix in that case.

Perhaps it does. I am a bit head-scratchy about pam and groupadd (&Co.)
atm.
I created a new chroot for my home server... just for the heck of it
(since I somhow became PAM guy around here) I enabled PAM.
I got PAM auth failures trying to use groupadd as root. Dunno why.
I thought of general borkedness or whatever... especially when the
ncurses recast kept failing on the chroot (/bin/sh not finding
libncurses.so.5 in the middle of install because this file is a symlink
to the just-now-not-existing libncursesw.so.5.6) --- I reckon that this
bug should have been fixed long ago...

Now, I have another PAM-aware chroot where I also tested the bug 13600
fix. This has no problems with groupadd.
And:

# cat /etc/pam.d/groupadd 
#
# The PAM configuration file for the `groupadd' service
#
# modified!
auth            sufficient      pam_rootok.so
auth            required        pam_unix.so
account         required        pam_unix.so
password        required        pam_permit.so

What suggests, that bug 13600 shouldn't be it. I even tested PAM by
suid'ing groupadd and executing it as normal user: After entering the
user's password, it allows group creation (and disallows with wrong
password).

The problem here is that apparently, under some circumstances, the
shadow tools (and everyone else?) bork up with PAM.
We just have to find out what it is.
I don't see the reverted shadow commits related to that, it's an effect
that groupadd fails there, not a cause.
It should succeed at that stage.

The second harmful effect here is that the whole shadow cast fails,
combined with castfs, I guess. Because without castfs, no installed
files would be missing (am I wrong here?). the installation of
important stuff already happened.
It would be much saner if the dispelled shadow would be automatically
restored if the updating cast fails at some stage ... or not be
dispelled before the install is totally done inside the castfs.


Thomas.