5:22 p.m.
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