On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:
> Debian has always lacked an explanation of what the various users and
> groups are for. Such a document is useful for sysadmins who must
> determine the correct way to use various users and groups. It's useful
> for developers as well, and it might help us find unused users and
> groups, or find unstated requirements about use of users and groups that
> could be put in policy.
>
> So here's a start. There are a lot of unanswered questions; can you help me
> answer some of them?
>
> ------------------------------------------------------------------------------
[snip]
> games:
>
> Many games are sgid to games so they can write their high score
> files. This is explained in policy.
>
> HELP: My system has no files owned by user games, and I don't see
> the point of the user, aside from symmetry.
Have several binaries in /usr/games with group "games". Some of
them don't work at all if the user isn't in group "games" --
mostly for accessing/writing scores. Also, probably for
powertripping sysadmins ;0
> man:
>
> The man program (sometimes) runs as user man, so it can write cat
> pages to /var/cache/man
>
> HELP: My system has no files owned by user man, and I don't see
> the point of the user, aside from symmetry.
Given changes in man-db to prevent local exploits, I'm not sure
the cache is even used anymore by default.
> postgres:
>
> HELP: Presumably used by the postgresql database?
User postgres owns all the files in /var/lib/postgresql. It
needs to to enforce proper security. Think there's a similar on
for mysqld ? This is pretty standard for databases management
systems.
> www-data:
>
> HELP: Er, I should know this, but this box doesn't run apache and
> I'm offline.
Not quite sure on the argument for www-data.www-data vs.
nobody.nogroup. www-data shouldn't own any files, AFAICT.
Guess the idea was to have web server processes have a distinct
user/group so if they get exploited the cracker can't do
anything with other processes of user nobody (not sure that'd
make me sleep any better).
> backup:
>
> HELP: ?
Presumably so backup/restore responsibilities can be delegated
to someone without full root permissions?
> adm:
>
> HELP: On my system, use of group adm is confined entirely to
> /var/log, and I've never seen the point. Oh, and
> /dev/xconsole is owned by group adm, but that may be a
> (local?) bogosity.
Seem to recall a while back /dev/xconsole had perms changed to
group adm, so access could be restricted. Something of a
security consideration. Probably a similar idea to "backup",
a user/group with resticted, but extra priveledges. Possibly
obviated by things like sudo. Seems mostly related to
monitoring activities.
> disk:
>
> HELP: Well, I have some disk devices in /dev/ owned by the group,
> but I can't see the point. On another system, I noticed that some
> of the files lilo puts in /boot/ are also owned by disk. I
> can imagine local uses for such a group, like if you want to
> give some users in the group direct access to some hard disk.
> But these uses I've found on my systems seem to preclude
> doing that easily; if I put a user in group disk here, they'd
> have write access to the root filesystem.
Not sure why partitions/drives aren't just owned by root.root.
Membership in group "disk" confers dangerous capabilities akin
to membership in "root".
> staff:
>
> HELP: So, /usr/local and /var/local are owned by it, but how's it
> differ from say, adm, and what's the historical meaning, and
> the current purpose?
Allows local users to add local modifications to the system
without needing root priveledges. May differ from "adm" as
that group seems more related to monitoring/security. See also
group "users" for comparison...
Not sure if they helps any (I sure as heck don't know what all those
system groups are for). Would be nice to have all the system users and
groups documented (and to clean out any unnecessary cruft).
--
Eric G. Miller <egm2@jps.net>
