Your message dated Thu, 15 May 2008 08:48:52 -0400
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#481248: libuuid1 greps /etc/passwd instead of calling
getent
has caused the Debian Bug report #481248,
regarding libuuid1 greps /etc/passwd instead of calling getent
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
481248: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481248
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: libuuid1
Version: 1.40.8-2
Severity: serious
from the postinst:
> if ! grep -q libuuid /etc/passwd; then
directly grepping /etc/passwd looks suspicious.
why isn't the call to groupadd guarded as well?
--- End Message ---
--- Begin Message ---
On Thu, May 15, 2008 at 08:30:18AM +0200, Matthias Klose wrote:
> > Using getent instead of grepping /etc/passwd would suppress adding a
> > local group if libuuid were defined in Yellow Pages, I suppose. But
> > having an extra entry in /etc/passwd is hardly the end of the world.
>
> I did set the priority because it looks like it will fail the install
> if the user already exists in NIS. Please downgrade if it doesn't fail.
No, it won't fail because useradd and groupadd are so low-level that
they only futzes with /etc/passwd and /etc/groups. And so for this
reason, I would argue this isn't a bug at all.
Both adduser and useradd only work by adding entries in /etc/passwd;
there's no way you can create new user accounts in NIS from NIS client
machine. (The obvious security problems with doing this are left as
an exercise for the reader.) Given that it is impossible for system
administrators to guess ahead time all possible user accounts that
might need to be created by Debian packages at installation time (one
ones might crop up at any time), the only wise thing for a sane NIS
administrator to do is simply not to assign any static user ID's in
the 0-1000 range. Most of the NIS HOWTO guides simply tell you not to
assign any user accounts out of the system range (i.e., 0-1000) out of
an NIS map. (The security implications of not doing that in terms of
being able to attack an individual NIS client machine are also left as
an exercise to the reader.)
So because (a) useradd only works on /etc/passwd, (b) dynamically
created system accounts must be created on the local /etc/passwd, so
only an insane NIS system administrator would try to create libuuid in
the system map, and (c) even if the did, the local one would override
the one exported by NIS, which would be the right thing in this case
from a security point of view ---- I don't believe this is a bug at
all, and I'm closing it.
Best regards,
- Ted
--- End Message ---
