remove fedora-usermgmt?

Sat Mar 10 23:22:43 UTC 2007

On Sat, Mar 10, 2007 at 04:31:56PM +0100, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> > On Sat, Mar 10, 2007 at 11:25:09AM +0100, Thorsten Leemhuis wrote:
> >> Axel Thimm schrieb:
> 
> Just a note here: I don't want to advocate for fedora-usrmgmt, I just
> want to understand where the problems with it are.
> 
> Further: I agree that having a bigger fixed uid space for packages would
> be the best solution, but we haven't one ATM afaics.
> 
> >>>> Can somebody *please* show me two detailed examples where using
> >>>> fedora-usermgmt in a package does something bad/odd on peoples
> >>>> systems in the default install (e.g. in case the admin didn't set it
>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>> up)? tia!
>      ^^
> >>> Please, there are two infinite threads with examples and arguments in
> >>> them.
> > [...]
> > Of the top of my head, there are more in the thread, feel free to
> > setup a wiki page:
> > 
> > a) package A and B assume the user foo is at base+42. System installs
> >    A, admin configures fedora-usrmgmt, system install B => desynced
> >    uid assertion
> 
> As I said, I wanted examples where the admin did "not* set it up (the
> default). Then fedora-usrmgmt works just like a normal useradd, doesn't it?

The admin may not even be aware that package A has been installed via
fedora-usrmgmt. It might have been installed as part of anaconda, see b)

> Further: Is packages A and B both assume  base+42 then we did something
> wrong, didn't we?

Why? Imagine A being something like apache and B needing to use the
same user.

> And if the admin configures fedora-usrmgmt so that is uses a
> uid-space where some uid's already are used then he did something
> wrong, didn't he?

That's not what this is about, I hope the explenation about clarify it.

> > b) same as above, only that now thge admin wasn't "sloppy", but
> >    anaconda installed A.
> 
> Can't follow, sorry.

Well, consider this method being deployed so much that "F7 prime"
contains package A, e.g. A is installed from DVD and the admin never
had a chance to configure the system before the first fedora-usrmgmt
controlled package hit the system.

So A is always installed with the default fedora-usrmgmt
behaviour. Then the admin gets his first shell login on this system,
and even though configuring the flaoting uid space is the first thing
he does, he already slipped package A, and package B will never be
able to "predict" the uid used by package A.

> > c) Admin buys fedora-usrmgmt "feature" set and *relies* on keeping foo
> >    the same across all his systems, forgets to configure system 23 after
> >    the bare bone installation, uids get mixed, possibly exposing
> >    sensitive information under another uid.
> 
> It's not fedora-usrmgmt's fault if the admin forgets something. He with
> fedora-usrmgmt at least has a chance to use the same uid on all his
> systems afaics, which he would not have without it. Or am I missing
> something?

Yes, that the system becomes far more fragile, non-deterministic and
insecure. An admin is required to show far more discipline here than
in any other part of the system configuration. At least other errors
with similar sloppyness in configuring the system don't expose
security relevant parts or require reinstalling the system from
scratch.

> > d) Packager buys fedora-usrmgmt "feature" and relies on the
> >    fixed/semi-fixed approach, but is not aware that on almost 100% of
> >    user deployment noone has configured fedora-usrmgmt and therefore
> >    fedora-usrmgmt is just plain old useradd. so he tests with
> >    different assertions and the package fails on the tyopical user
> >    deployment.
> 
> I asked for examples where is does harm on users systems.

That's such an example. If the packager tested it in an environment
where fedora-usrmgmt is activated and provides
deterministic/predictable/ static uids, but breaks if fedora-usrmgmt
defaults to useradd -r then it harms user systems.

> Further: if it is just plain old useradd then nobody is hurt, isn't it?

It was an explicit assumption in d) that this package really needs
more than plain old useradd.

And also add

e) The fedora-usrmgmt is a configure-once-never-reconfigure option. Is
   this really evident to the end user/admin? Do we require the admins
   to be that much aware of the background of fedora-usrmgmt to
   understand that they can only nail the floating window once and
   that they will break havoc if they think they can relocate it by
   reconfiguring the base uid? There is nothing else comparable to
   this other than the type of filesystem maybe you chose.

> > The method is fragile to say the least, and requires iron discipline
> > form the admin with no room for errors. [...]
> 
> I'd say you are shooting over the top here.

Maybe the clarifications help to see the pitfalls that lie ahead.

> > User management is delicate and fedora-usermgmt is not the way to go.
> 
> It solved a problem afaics, that we have no better solution for in RHEL5.

Which and whose problem? I still think that less than 100 people ever
used that mechanism. Let's put that into perspective.

> Does it do any harm if not or correctly configured?

The question is not whether it does any harm while it's dormant. You
could just the same argue on whether

cat > /sbin/suicide << EOF
#! /bin/sh

echo Told you so
rm -fr /
EOF
chmod +x /sbin/suicide

is harmful as long as you don't call it.

> Don't know, I'm still looking for two examples that show me where it
> does.

You got more than two examples.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20070311/b5055153/attachment.sig>