Re: user private groups and a src group
(This message is going to both the debian-devel and debian-user lists.
Unless someone tells me otherwise I'll assuming this discussion
belongs on debian-devel and leave the thread on -user to peter out.)
Daniel Quinlan writes:
> I really do think there must be a better (read: low level) way to go
> about this than storing every user in /etc/group.
Yes, clearly there are several. The first practical one I can see is
to unify groups and users. This would involve major changes the the C
library at the least. Incidentally, this would still mean that every
`user' would have an entry in /etc/group (much as every user has in
/etc/shadow); perhaps every `group' might have an entry in
I don't think we're ready to do this kind of thing to Linux, and if we
did we'd find precious little acceptance. Detailed discussion of such
schemes belongs in comp.unix.*.
> I mean I like the idea and if Debian implemented it as Ian Jackson
> describes, I would be happy. However, we are talking about ... an
> ugly kludge -- even if it is a good thing, I worry about scaring
> people away from Debian.
Personally I don't think it's an ugly kludge any more than (say)
setuid programs or indeed Unix permissions in general.
I don't think this will scare people away from Debian - it's too small
an issue. If we put the explanation (perhaps derived from my posting
a few days ago) in the FAQ (Linux or Debian) we won't get too many
people asking why it's done, either. I'll have to make sure all the
manpages are up to date, as well.
He also described it as:
> ... change away from the Linux norm ...
I hope you're not trying to use this as an argument against it.
Debian itself is a change away from the Linux norm. They key thing is
to tell and show people that the change is for the better.
Bradley Bosch writes:
> I think the BSD group semantics mount option is preferred over the
> setgid directory approach as this allows easier deviation from whatever
> is chosen as the default policy.
I disagree, for at least one reason in addition to those identified by
4. It violates the principle of least surprise. Files will be created
(with a umask of 002, remember) with odd group ownership for no
readily apparent reason. The same could be said of setgid, but the
g+s bit in the directory permissions is much more visible and is the
kind of thing that people would believe might have this effect.
This could be seen as another facet of Bradley Bosch's argument and
Matthew Hannigan's reason 1 (that using BSD you can't get the V7
semantics back for individual directories). Using setgid allows
selection on a directory-by-directory level; whereas using bsd
semantics allows selection on a system-by-system level.
The question is really which is most likely to be required, and how
much effort it is to work around if one needs something that's not
I believe that we're much more likely to want to turn off this feature
for individual directories (/tmp and /usr/tmp come to mind
immediately). In practice, I don't think that many sysadmins would
bother turning it off even if we made it easy by mounting everything
This is because the technical cost of the scheme is just a larger
In both cases, trying to work round the problem if the "default" was
wrong would be very difficult.
I think it's definitely *not* worth forcing some sysadmins to go
through hell just so that a few others can have a smaller /etc/group.
Wayne Schlitt wrote:
> The one thing that I am really concerned about is whether Linux (and
> Debian in particular) can support lots of different groups. I seem to
> remember problems about a year ago with some fixed sized tables. If
> you implement this, you should probably make sure that Debian runs ok
> with say, 400-1000 groups.
I wasn't aware of this. Can you remember any of the details ?