Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Talking about system accounts...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Talking about system accounts...
  • Date: Wed, 28 Jun 2006 15:09:05 -0500

On Jun 28, Thomas Orgis [thomas-forum AT orgis.org] wrote:
> The system user account handling has to be improved - IMHO, of course.

Yes. It's one of the worst parts of the current system.

> I previously had issues with more basic accounts than mysql simply
> because I didn't install from ISO. ISO cheats (or did so in the past)
> by providing a /etc/passwd that fits the basic requirements like having
> group tty 'n stuff.
> That file doesn't (didn't) even need to agree with the accounts list
> in grimoire...

This is because unfortunately various ISOs have come with conflicting uids
pre-defined, so the grimoire isn't really sure what it's getting into. For
the basic ids that spells should be able to assume are there we need an
smgl-ids spell that creates them (similar to what smgl-fhs does for
directories), and the installer would then use this spell to set up the
initial system. This is http://bugs.sourcemage.org/show_bug.cgi?id=9788

> Also, not every spell which needs special accounts does create them
> (I'm sure there is at least one left;-), since the situation where this
> account doesn't yet exist is too exotic.

Some of them spells should be able to assume are there, or base system
spells get too ridiculous checking everything before they do anything.

> Ideally, every spell needing it would call create_account and/or
> create_group and all ist fine... but that doesn't work in my opening
> example.
> I remember that that case where I create some other user with an id
> that is destined for mysql in grimoire is considered as "user messed up,
> his fault" by some of you, but I disagree to this.
>
> 1. When smgl predefines account names and ids, but only creates them when
> needed, it calls for the trouble, not the admin creating some account
> with a free id that _may_ be occupied later by some spell.
>
> 2. There are situations where the user/admin not even has control over
> all accounts / ids. This is the case with the box I casted mysql on,
> It is my workstation in the network at ... work.
> I am root there, but the box is embedded in the standard NIS + NFS
> environment there, with some user ids being there since deep in last
> century.
> there are many NIS accounts with id<1000, some with id<500 - and _of
> course_ there is someone with the id 121.
> I think smgl should be flexible enough to handle that.

You are right.

> At least the part with the conflicting numerical ids should be easily
> solvable.
> Having the current experience in mind, I opt not for a fully predefined
> /etc/passwd what would be logical when we predefine all ids anyway
> (IMHO), but for simply _not_ defining the ids.
> The create_account and create_group functions should be smart enough to
> search a valid free id for themselves.
>
> But before I start hacking anything in that direction, I want some
> agreement on how we really want it to be.
>
> Some ideas that come to my mind:
>
> 1. It should be configurable what range of ids is to be included as
> candidates for system accounts.

Yes.

> 2. The functions should _fail_ if they cannot find one (current behaviour
> with unavailable id assumes that user id 121 existing means mysql user
> existing, which is _wrong_).

Yes.

> 3. The functions should rather check if the _name_ is already there,
> but possibly still fail (or at least warn) if corresponding id is out
> of specified system id range.

Maybe, I guess you're wanting to prevent a user named 'mysql' getting
ownership of things?

> 4. It should still be possible to predefine the ids, p.ex. if one wants
> the same setup of user ids on a range of machines - simplest realization
> could be just copying a passwd/group with all needed accounts defined...

This is a main one to me, since it's reasonable for people to want services
to usually use the same ids between systems (within some limits). This
eases things like moving files between systems and not having to patch up
all the ownerships afterward. Ideally yes they set that up ahead of time
themselves but that's not always practical. It would be ideal if the
system allowed a service to want a default id or range of ids and if that
failed ask the user if it should try to find another free id in the system
range or fail. This would have to be done ahead of time during the
CONFIGURE stage, though, not during install or anything.

> I'd even volunteer to code that stuff myself (as I seem to be the one
> having the hardest headache with current solution;-), but as I said,
> some discussion on what is needed and sensible ... is needed and a
> sensible thing to do first.
>
> So, please:
>
> Input, anyone?

This is a thorn in my side as well but I haven't been able to spend time on
it vs. other things yet. I think it would be really helpful if someone
with interest in the problem worked it out. You sound like you're thinking
about it from the right direction, I say file a bug for it (or hijack one
of the existing ones) and draw up an unambiguous spec there on on the wiki,
let people agree to it, and then implement it.

Attachment: pgp9Y46KpAYRz.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page