Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote:
> This is annoying as this means that Debian machines won't integrate
> correctly in foreign networks. Why don't these groups have a name
> specific to Debian? For instance, I've noticed that exim4 creates
> a Debian-exim group. So, why don't other packages follow the same
> way, with a Debian-* group?
1. Too long (ps, top, ls -l etc. will not be able to display the whole
name)
2. When there is an upstream default for the group name I'd be most
annoyed if Debian diverged from that
3. There are no solaris-*, aix-*, redhat-* etc. groups and still these
systems can be integrated in the same NIS domain quite nicely (been
there, done that). Of course, that needs some planning _before_
setting up the NIS domain...
> The reason given by the Debian policy is:
>
> Because some packages need to include files which are owned by these
> users or groups, or need the ids compiled into binaries, these ids
> must be used on any Debian system only for the purpose for which
> they are allocated.
>
> But the ids could be changed at package installation time, and it
> should be possible to avoid ids hardcoded in binaries... Anyway,
> since the the /etc/group file has the priority, I don't think this
> is a problem (except the fact that such groups can get hidden) if
> packages use local group names (Debian-*) to avoid clashes.
Ok, let's see:
- root, daemon, bin, sys, adm, mail, news, uucp, www-data, nogroup: do
not belong to any single package so cannot be changed dynamically
(just think of the implications if the mail group ID changed when you
install a different MTA and you suddenly can't read your mail -
brrrr...)
- tty, disk, kmem, lp, dialout, fax, voice, cdrom, floppy, tape, audio,
video: used for device nodes, so cannot be dynamic
- man, sudo, shadow, utmp, sasl, plugdev: either too basic or too
special so it's not worth allocating them dynamically
- backup, operator, list, irc, gnats, games, staff, users: these
historically exist and some packages may have them hardcoded for
historical reasons. Also they do not belong to any single package so
they cannot be allocated dynamically
- there are 3 more left in /usr/share/base-passwd/group.master that I do
not care to look up
> Yes, there are several gids < 100. In particular, slocate has gid 21,
> which is group fax under Debian.
Then your NIS setup is _broken_ and Debian can do nothing about it.
Complain to your local NIS administrators.
> Well, I was asked the question, but the dialog box said that if I
> didn't answer positively, my Debian system would not work properly.
> You see...
Then you got what you've asked for.
> This is not the case. This is purely Debian's slocate system, and
> the files are stored in /usr/bin and /var/cache, which are local.
>
> > - If you want the slocate database to be stored on local storage then
> > you should not have put the slocate group in NIS in the first place
>
> But this isn't me that put the slocate group in NIS. I couldn't do
> anything about that (I'm not the sysadmin).
I repeat again: if you want to use NIS, _you_ have to play by the rules
set by the NIS administrators. If the NIS setup is broken, _you_ will
have to fix the mess manually. There is absolutely _nothing_ Debian can
do about it so please stop complaining in the BTS.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3 : http://www.lpds.sztaki.hu
---------------------------------------------------------
Reply to: