Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Mar 13, Thomas Orgis [thomas-forum AT orgis.org] wrote:
> 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.

Yes, I don't mean the config files and binaries aren't there, but that pam
can't obey pam.d/groupadd without shadow available for authentication.

I'm not 100% sure this is isolated to using staged_install but it probably
is.  I tested it on a castfs vm to reproduce it because that's the test vm
I had up at the time but that's the only one I have that uses devel
sorcery.
 
> > Nothing to do with the 13600 fix in that case.

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

I've tested 13600 independently, it doesn't have problems by itself.  It
just is coincidental it talks of groupadd too.

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

This isn't really a mystery: shadow is dispelled on the real system, but
installed in the stage_root, which doesn't help the real system.  We try to
add a group, pam can't authenticate against shadow, so the groupadd fails
and the install stops before doing anything else with the staged files.

The commits had to be reverted for now because as is it just doesn't work
and it doesn't work very badly.

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

You're probably right.

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

This too.

Attachment: pgp_HczB5cdLQ.pgp
Description: PGP signature