Re: System-users and-groups?


Moe Trin wrote:
On 8 May 2006, in the Usenet newsgroup alt.linux, in article
<1147076158.977262.125600@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Koppe wrote:

What I really would like, is to see some standard,
recomandation or summary over the common users and
groups on a Linux/Unix system -- how they should be
used (e.g. which files/directories they should own and
which processes they should run).

I haven't seen such a recommendation in a long time.

But you have? Where?

Typically, unless you
have some very specific reason to change things, you should keep the ownership
as the distribution installed it.

Was sort of toying with the idea of rolling
my own distro... maybe.
(right around the time the tower gives a flock
of pigs clearing from runway one-niner at JFK
International...)

You are quite welcome to make your own
analysis of each binary on your system, and decide what permissions and/or
ownership is appropriate, but have you looked at the size of that task?

Not necessery *that* hard of a task. Changing
group for everything under bin/sbin to bin shouldn't
change too much... even changing the owner to
bin shouldn't do so much. Then I could just look
for files set UID and/or GID and set suitable owner
and/or group for them.

AFAIK, a Linux system *must* have at least two users
and two groups -- the root-user and root-group, and
the bin-user and the bin-group...

Were that the case, why the convention to have "system" UIDs below 50 or
100 or similar, and user UIDs above that?

Of course all system have more users and groups, but
I (am sure I) read somewhere that the only users and
groups you *had to* have -- wheter it was in accordance
to some standard or some kernel internal I don't know --
was root and bin... obviously such a system wouldn't
be sufficiantly compartmentlize to be very secure.

My point is, that with all the *other* users and groups,
name and ID # can be chosen (more) freely... root and
bin have fixed ID #s. Although the daemon user/group are
usually given a very low ID (2,3,4,...), you *could* give it ID=50
and call it lucifer if you'd like... you're not that free with root
and bin. (Guess you could change the name, but you're
stuck with the ID.)

My main problem is that the use of users and groups
varies hugely between distros... on top of that, there
are a number of users and groups (mostly for various
subsystems like man, halt, sync)

The 'halt' (and perhaps 'shutdown') user was a mechanism to allow certain
users (who were given the password) the ability to shutdown the system. Look
at the "login shell" in /etc/passwd for those users, and see that logging in
as that user runs that command. Same is true for user 'sync'. In most
installations I've seen, these accounts are disabled (* in password field)
but a root user could log in as that user in order to run that command - and
may or may not save some keystrokes. I've also seen those accounts reset to
have '/bin/true' as the login shell.

OK, that make sense...

But still there seem to by many users and groups that
seems to do nothing... so why put them there? Surely
they're supposed to do *something*.

I would think it would be desirable to run various system-processes
(daemons) with as low privliges as possible, and to otherwise restrict
access as much as possible.

That is in general what is done.

Yet almost all runs as root...

Shouldn't the man-command be run SUID to the man-user?

Why? What need do you see?

Me neither... I was just thinking since there was
a user and a group for it, why not use it?

Shouldn't the man-pages and assosiate directories be owned by the
man-user and man-group?

Distribution dependent. If your man command uses /var/catman/ the man
binary may be 'SGID man' to be able to write the formatted man pages to
that directory, but that's about it.

Wouldn't it make sense to let some users become
members of the man-group, so they could add, edit or
delete man-pages?

No.

Take the bin-group... on some system, this group owns the various
bin-and sbin-directories and most of the files (executables) in them
(unless the executable is run SGID and therefor must belong to some
special group).

OK

Thus I would think that a normal user made member of the bin-group,
would/could have enough privliges to install (copy in) or remove simple
commands (e.g. ls, ps, vi; as opposed to larger packages that would
require higher privliges).

Oh... newbie.

Nope...

Ever wonder why '.' is not commonly in a user's PATH, and
why it should NEVER be in root's?

No, I *know* why.

Let's just say that's the result of
decades of experience at (...) teaches typing skills.

I'm not suggesting making every Joe, *** and Jane
a member of the bin-group... and certainly not people
likely to pull juvinile pranks. But maybe some
experienced user... maybe root's non-root alter-ego...

This user could then add, remove and change permission
for *simple* commands (there still are a few commands
that have to be manually copied into place).

On some distros I have seen the odd daemon running as the bin-user, but
that is rather seldom... aren't there more daemons that could -- and
ought to -- run with less than root-priviliges?

Daemon? Sure - but a lot of that depends on how the binary is written, and
how it is compiled in addition to what the daemon is trying to do.

I would think that the adm-user could run things like syslog.

[compton ~]$ grep auth /etc/syslog.conf
# Don't log private authentication messages!
*.info;mail.none;authpriv.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
[compton ~]$

There might be one reason.

Yes, but then again, it would be just as easy to
restrict some logs to adm-only as to root-only...
If some user was given permission (by being added
to the adm-group) to view additional logs, one would
have to assume that user would be trusted.

I assume that users made member of the root-group can
preform system-tasks with *near* root-users
privliges... but I don't know if it's common (or wise)
to make ordernary users members of this group.

That's what 'su' and 'sudo' (and similar) are for. Assume John Doe is in
user 'root' and decides to install an "improved" /bin/login. Or to first
chmod certain files in /boot/ and them remove them. Tracks? What tracks?

But again it's ultimately a question of trust (and convinience)...

Besides, if two people is locked *alone* in an empthy room
and one of them end-up being murdered, it's not really a
mystery who did it. Likewise if root allow one other to get
near-root priviliges and the system suddenly ends-up toasted
while root wasn't using it.

-Koppe

.