Re: uid/gid - comments?
On Wed, Sep 01, 1999 at 10:40:38AM +0200, Andreas Jellinghaus wrote:
> > This is common enough... should we perhaps create a system wide file, that
> > maps default {user,group}names to local {user,group}names?
> >
> > eg, in /etc/local_names:
> > mysql mysql
> > ups ups2
>
> no, please do not add another level of indirection.
> most daemons have configureable user id's anyway.
Yes, but they're configurable at build time, which is problematic if the
uid/gid is already taken on the system on which they're installed.
> it can go wrong and it will. for example with updateing slink
> to potato and installing new potato packages - nothing can prevent
> that i might have created a user id, that is reserved in potato.
Umm... the entire point of this proposal is to avoid actually needing to
reserve id's, and prevent the problem you mention.
> and if you realy want, there is always a way to shoot yourself.
Of course; I just think that this solution makes it harder to shoot
yourself than what we have now.
> so we should better find a smart way to handle this.
>
> for the novice user: they either may not use the package or have to remove the
> user id before installing the package.
>
> for the experienced user: take care of it yourself.
> changeing permissions (suid/sgid on apps and /var/lib/* stuff) is
> not that difficult. editing for example http.conf to use a different
> user id is also easy.
But sometimes they're compiled directly into the binary.
> anyway, i only expect less than 0.1 percent of debian users to suffer
> from these problems. on the other side, if you add another level of
> indirection, then everyone will have to learn that new concept and live
> with it.
No-one will have to learn the concept if it doesn't affect them (it all
happens in the magic {pre,post}{inst,rm}'s). If it does affect them then
it would seem that they'd prefer such a system which makes it possible to
work around their problem without changing existing user ids or recompiling
packages.
Or if you were referring to developers, then I think that we need some sort
of policy about this anyway (better than the current situation with mysql,
for example), and creating the mentioned scripts would probably make these
developer's lives easier, not harder.
> please remember why windows is not good. too many levels of indirections,
> unknown strange concepts and that stuff is part of the windows problem.
>
> always remember: keep it simple !
But increased organization _is_ simplicity. Every package doing something
that's broken in different and exciting ways is not.
-- Nathaniel
Reply to: