[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exploring debian's users and groups



Eric G. Miller wrote:
> > 	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

Hmm, I'm not sure I understand. Yes of course you have games owned by
group games. But what is the user good for?

>         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.

I wonder why it needs a staticall allocated id though?

> > 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.

Well it does look like only group adm can read it. And I can't run
xconsole manually anymore, though it works if run from xdm, as it is by
default. I must confess I don't see the utility of that.

But I take your point that group adm seems to be entirely a system
monitoring group. The user seems unused, as far as I can tell.

> > 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...

Hmm, I guess. Odd names if that's the distinction between them.

-- 
see shy jo



Reply to: