Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] user creation optional

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Thomas Orgis <thomas-forum AT orgis.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] user creation optional
  • Date: Sun, 23 Jul 2006 04:13:35 -0700

On Sun, Jul 23, 2006 at 12:49:46PM +0200, Thomas Orgis wrote:
> Am Sun, 23 Jul 2006 11:32:15 +0200
> schrieb Arwed von Merkatz <v.merkatz AT gmx.net>:
>
> > On Sun, Jul 23, 2006 at 02:20:52AM -0700, seth AT swoolley.homeip.net wrote:
> > > user and group creation should be optional. If a user or group
> > > creation
>
> I am convinced that there is improvement needed in various places of
> user/group handling... and also kindof uttered the plan to put my
> thoughts about this in code form; well, if I find the time... My first
> point was having flexible uid/gid (or at least the user being able to
> configure that, p.ex. to fit in certain networks (NIS,NFS) where some
> ids are predefined). Another one is making a chroot install more
> non-invasive to host system. Creation of users/groups in host system
> to install stuff into the chroot is just not a good thing.

That is certainly something which is important to have (user-defined
id lists)

>
> > > Eventually, we could, with the stage_root help, even get the entire
> > > cast
> > > process pulled into a non-root user except the install stage. making
> > > the user and group creation optional would make it easier to cast as a
> > > user later.
>
> That would be a step. Wha I already thought about (for not touching
> the host system user database) is adding the lines to
> $INSTALL_ROOT/etc/passwd and change all chowns to use the id instead
> of the name - so that the users don't have to be set up in the running
> system. Maybe one could use installwatch to catch the chowns like it
> does with file creation?

I actually think we should be using the names instead of the ids in our
functions and making it completely symbolic (except of course the
predefined ids you mention above). This prevents id conflicts. Any
numeric chowns could be caught, but there would be no way of knowing if
the code resolved the name to id at first without tracking previous
glibc calls (ouch) (and the program can do this without library help
too). We could catch numeric id chowns and see if they are valid, if
they are not valid, we could consider it an error (no spells should be
installing files without a symbolic owner). We'd find any issues pretty
quick and be able to patch the spells.

>
> > >
> > > I'm just saying there are a few good reasons to think about going this
> > > direction.
> > >
> > > Any comments? If reaction is amenable, I'm going to file a bug
> > > assigned
> > > to myself to start this process.
> >
> > I like the idea, though it might be hard to do for some spells. There
> > are several programs that do chown/chgrp in their install process,
> > failing if the user doesn't exist. We'd have to fix all those to work
> > both with and without user/group existing.
>
> Actually, if installwatch would catch the chowns, that would be no
> issue, as far as simple chown usage is concerned.

Yeah, stage_root/installwatch could catch this (more coding of course).

> But what broke
> staged installs already and will continue to be difficult is setup
> work in install step that uses the installed software and users to do
> some complex stuff (I think of mysql, or was it postgres, even?).

Yep, it really shouldn't be doing this, and it's probably good that we
catch these -- they could probably be moved to POST_INSTALL (or
FINAL/whatever we decided).

>
> So, I am totally in favour of getting some movement going to make the
> account handling better. I'd perhaps like to join that movement with
> own coding if possible... but I still have some spells to do, not to
> forget RL;-)

Sounds good. Once we get a plan together, we can bugify the components
and divide up the labor, too.

Seth




Archive powered by MHonArc 2.6.24.

Top of Page