users-and-groups

To: debian-devel@lists.debian.org
Subject: exploring debian's users and groups
From: Joey Hess (joeyh@debian.org)
Date: Tue, 7 Aug 2001 01:35:48 -0400
Cc: debian-doc@lists.debian.org, debian-user@lists.debian.org,
base-passwd@packages.debian.org
User-Agent: Mutt/1.3.18i

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?

------------------------------------------------------------------------------

Many users have a corresponding group, and these pairs will be treated together:

root:

Root is (typically) the superuser.

daemon:

Some unprivileged daemons that need to be able to write to some files on disk run as daemon.daemon (portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users.

bin:

HELP: No files on my system are owned by user or group bin. What good are they? Historically they were probably the owners of binaries in /bin? It is not mentioned in the FHS, debian policy, or the changelog of base-passwd or base-files.

sys:

HELP: As with bin, except I don't even know what it was good for historically.

sync:

The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system.

HELP: If that is the only purpose of user sync, then group sync seems not very useful. The sync user could just as well be in nogroup.

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.

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.

lp:

HELP: I assume it's used by lpr, as I have not owned a printer in years and have not used lpr in longer, I can't say what exactly the user is used for or what the group is used for. Or is the idea to make the printer device owned by one or the other, to let eg, users in group lp cat files to it directly?

mail:

Mailboxes in /var/mail are owned by group mail, as is explained in policy. The user and group is used for other purposes as well by various MTA's.

news:

Various news servers and other associated programs (such as suck) use user and group news in various ways. Files in the news spool are often owned by user and group news. Programs such as inews that can be used to post news are typically sgid news.

HELP: I notice that /etc/news/leafnode/config and even /etc/news are here owned by news.news. Which is odd, because those arn't things the programs should be editing on the fly. What gives?

uucp:

HELP: Presumably used for UUCP, which I know nothing of.

HELP: Why is minicom owned by group uucp? Is this a bug?

proxy:

Like daemon, this user and group is used by some daemons (specifically, proxy daemons) that don't have dedicated user IDs and that need to own files. For example, group proxy is used by pdnsd.

HELP: What uses user proxy?

majordom:

Majordomo has a statically allocated uid on Debian systems for historical reasons.

HELP: Do we still even ship that buggy old POS? And can someone remember what the hysterical raisins were?

postgres:

HELP: Presumably used by the postgresql database?

www-data:

HELP: Er, I should know this, but this box doesn't run apache and I'm offline.

backup:

HELP: ?

operator:

HELP: No files owned by it here, what's it good for?

list:

HELP: Evidently used by smartlist?

irc:

HELP: Why does an irc daemon need its own static user and group?

gnats:

HELP: Evidently used by gnats. And it needs a static set why?

nobody, nogroup:

Daemons that need not own any files run as user nobody and group nogroup. Thus, no files on a system should be owned by this user or group.

Other groups have no associated user:

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.

tty:

Tty devices are owned by this group. This is used by write and wall to enable them to write to other people's tty's.

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.

kmem:

/dev/kmem and similar files are readably by this group. This is mostly a BSD relic, but any programs that need direct read access to the system's memory can thus be made sgid kmem.

dialout:

HELP: Is this used for /dev/cua devices or something?

fax:

HELP: ?

voice:

HELP: ?

cdrom:

This group can be used locally to give a set of users access to a cdrom drive.

floppy:

This group can be used locally to give a set of users access to a floppy drive.

tape:

This group can be used locally to give a set of users access to a tape drive.

sudo:

HELP: Nothing uses it here, and I have sudo installed.. Maybe there's a way to only let users in this group use sudo?

audio:

This group can be used locally to give a set of users access to an audio device.

dip:

HELP: WHat did this group's name signify? DIaluP?

pppd may only be run by users in the dip group (and by root of course).

src:

This group owns source code, including files in /usr/src. It can be used locally to give a user the ability to manage system source code.

HELP: /usr/src is owned by group src and is setuid. This doesn't make files put there by foo-src packages necessarily be owned by group src though. If the intent is to make group src be able to manage source code, perhaps policy should say that foo-src packages make files in /usr/src owned and writable by the group (and files in tarballs dropped there likewise?)

shadow:

/etc/shadow is readable by this group. Some programs that need to be able to access the file are set gid shadow.

utmp:

This group can write to /var/run/utmp and similar files. Programs that need to be able to write to it are sgid utmp.

video:

This group can be used locally to give a set of users access to an video device.

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?

users:

While Debian systems use the user group system by default (each user has their own group), some prefer to use a more traditional group system. In that system, each user is a member of the 'users' group.

--
see shy jo

(oh no, a crosspost)

On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:

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

The man program (sometimes) runs as user man, so it can write cat pages to /var/cache/man.

> uucp:
>
> HELP: Presumably used for UUCP, which I know nothing of.
>
> HELP: Why is minicom owned by group uucp? Is this a bug?

Probably as a convenient but ugly way to get access to the serial port, or something.

> proxy:
>
> Like daemon, this user and group is used by some daemons
> (specifically, proxy daemons) that don't have dedicated user
> id's
> and that need to own files. For example, group proxy is used by
> pdnsd.
>
> HELP: What uses user proxy?

squid, at least.

> majordom:
>
> Majordomo has a statically allocated uid on Debian systems for
> historical reasons.
>
> HELP: Do we still even ship that buggy old POS?

Not if apt-cache is behaving itself today.

> postgres:
>
> HELP: Presumably used by the postgresql database?
>
> www-data:
>
> HELP: Er, I should know this, but this box doesn't run apache
> and
> I'm offline.

Used by apache as the user/group, typically is the user/group that owns Web content.

On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:

> uucp:
>
> HELP: Presumably used for UUCP, which I know nothing of.
>
> HELP: Why is minicom owned by group uucp? Is this a bug?

It also was (until recently?) setgid uucp, for modem locking. I believe it was removed for security reasons. There's talk about redoing serial port locking entirely now though.

> irc:
>
> HELP: Why does an irc daemon need its own static user and group?

Because no one wants to trust it? :)

It doesn't. Of course, removnig them is tricky.

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

Nope, not a bogosity. ADM is to read logs. I keep myself in group adm so that I can read syslog (and could use xconsole if so inclined) without having to su.

> disk:
>
> kmem:

Disk may have been a good idea at one point, but (like kmem) is essentially equivalent to root. Write access to any raw device is very likely to lead to system compromise, via VFS bugs if nothing else. Read access to kmem is a LITTLE weaker than root... but not much. Especially if root ever types his password.

> sudo:
>
> HELP: Nothing uses it here, and I have sudo installed.. Maybe
> there's a way to only let users in this group use sudo?

There is, sure, but the group isn't special in any way...

> dip:
>
> HELP: WHat did this group's name signify? DIaluP?

Dialup IP. apt-cache show dip, actually.

> src:
>
> This group owns source code, including files in /usr/src. It can be
> used locally to give a user the ability to manage system source
> code.
>
> HELP: /usr/src is owned by group src and is setuid. This doesn't
> make files put there by foo-src packages necessarily be owned
> by group src though. If the intent is to make group src be
> able to manage source code, perhaps policy should say that
> foo-src packages make files in /usr/src owned and writable by
> the group (and files in tarballs dropped there likewise?)

<gripe>(and that sticky bit causes no end of stupid errors when packaging... mostly alleviated by debhelper now, but still...)</gripe>

--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer

On Mon, Aug 06, 2001 at 11:11:18PM -0700, Daniel Jacobowitz wrote:

> > sudo:
> >
> > HELP: Nothing uses it here, and I have sudo installed.. Maybe
> > there's a way to only let users in this group use sudo?
>
> There is, sure, but the group isn't special in any way...

users in group sudo don't have to type their password when running sudo.

useful for, e.g., writing sudo wrapper scripts that are forked by an MTA such as postfix that refuses to run anything as root.

also useful for sudo wrappers to adduser or chg passwd type programs that are executed from a CGI script (after appropriate taint checking etc).

TMTOWTDI - the sudo group isn't strictly needed for this, you can also use the NOPASSWD keyword in /etc/sudoers.

craig

--
craig sanders (cas@taz.net.au)

Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch

Previously Daniel Jacobowitz wrote:

> On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:
> > dip:
> >
> > HELP: WHat did this group's name signify? DIaluP?
>
> Dialup IP. apt-cache show dip, actually.

And ppp as well. Being in group dip allows you to use a tool to dialin, group dialout gives you direct access to the serial port. A very useful distinction.

> <gripe>(and that sticky bit causes no end of stupid errors when
> packaging... mostly alleviated by debhelper now, but still...)</gripe>

Stupid bug in install..

Wichert.

--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wichert@wiggy.net http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Andrew Suffield (asuffield@users.sourceforge.net)
Date: Tue, 7 Aug 2001 14:03:15 +0100
Cc: base-passwd@packages.debian.org
User-Agent: Mutt/1.3.20i

On Mon, Aug 06, 2001 at 11:11:18PM -0700, Daniel Jacobowitz wrote:

> > irc:
> >
> > HELP: Why does an irc daemon need its own static user and group?
>
> Because no one wants to trust it? :)
>
> It doesn't. Of course, removnig them is tricky.

This is a bug in ircd. It setuid()s itself to a given UID on startup, if started as root, but doesn't know how to look up a name to get that UID - the UID is actually set at compile time.

It does not need a uid. The correct solution is to #undef IRC_UID in config.h, which will cause it to error and exit if started as root. It should then be started from an init.d script that runs it as a suitable user, which then need not be static.

--
Andrew Suffield (asuffield@users.sourceforge.net)
Dept. of Computing, Imperial College, London, UK

On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:
> postgres:
>
> HELP: Presumably used by the postgresql database?
>

All the data file in the postgres system are owned by that user and group. I think it's just a way of ensuring that no-one else can accedently access it.

> list:
>
> HELP: Evidently used by smartlist?

It's what the list archives are owned by as well as the user doing the sending and receiving of email.
--
Martijn van Oosterhout (kleptog@svana.org)
http://svana.org/kleptog/

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org, base-passwd@packages.debian.org
Subject: Re: exploring debian's users and groups
From: Tollef Fog Heen tollef@add.no
Date: 07 Aug 2001 10:04:32 +0200
In-Reply-To: 20010807162642.B1065@svana.org
Mail-Copies-To: never
Original-Sender: Tollef Fog Heen tollef@add.no
References:
20010807013548.A17529@kitenet.net><20010807162642.B1065@svana.org
Sender: tfheen@arabella.intern.opera.no
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Martijn van Oosterhout said:

Used by mailman as well.

Tollef Fog Heen
You Can't Win

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Rainer Clasen bj@zuto.de
Date: Tue, 7 Aug 2001 08:31:15 +0200
Cc: debian-doc@lists.debian.org, base-passwd@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net; from
joeyh@debian.org on Tue, Aug 07, 2001 at 01:35:48AM -0400
Mail-Followup-To:
debian-devel@lists.debian.org,debian-user@lists.debian.org,
debian-doc@lists.debian.org,base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
Reply-To: bj@zuto.de
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:
> sudo:
>
> HELP: Nothing uses it here, and I have sudo installed.. Maybe
> there's a way to only let users in this group use sudo?

sudo uses this group internally. Members of this group do not need to
type their password.

see /usr/share/doc/sudo/OPTIONS

Rainer

To: debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: "Eric G. Miller" egm2@jps.net
Date: Mon, 6 Aug 2001 23:36:57 -0700
Cc: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
base-passwd@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net
Mail-Followup-To: "Eric G. Miller"
egm2@jps.net>,debian-user@lists.debian.org,
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
Sender: "Eric G. Miller" egm2@jps.net
User-Agent: Mutt/1.3.20i

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?

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

To: debian-devel@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Sam Couter sam@topic.com.au
Date: Tue, 7 Aug 2001 16:46:22 +1000
Cc: debian-doc@lists.debian.org, debian-user@lists.debian.org,
base-passwd@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org,base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.3.20i

Joey Hess joeyh@debian.org wrote:

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

Wasn't there a proposal to remove it (and pre-formatted man pages along
with it) a while back? man running as set{u,g}id man is commonly
regarded as a security hazard, and preformatted man pages present an
easy DoS attack. With the mailing list archive search down, I'm having
a hard time finding the demonstration.

> www-data:
>
> HELP: Er, I should know this, but this box doesn't run apache
> and
> I'm offline.

Apache runs with this uid. Some people like to make their web pages
owned by this uid as well, but that's bad. Web servers don't modify web
pages, they just read them.

Apart from CGIs and other such nastiness, the web server could easily
run as nobody.

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

I use it so I can run VMWare using a real disk. I trust me not to crack
root.

> dialout:
>
> HELP: Is this used for /dev/cua devices or something?

Probably historically mixed up with uucp, fax and dip. I don't see why four
groups for serial port access are necessary.
--
Sam Couter | Internet Engineer | http://www.topic.com.au/
sam@topic.com.au | tSA Consulting |
OpenPGP key ID: DE89C75C, available on key servers
OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Wichert Akkerman wichert@wiggy.net
Date: Tue, 7 Aug 2001 11:23:25 +0200
Cc: base-passwd@packages.debian.org
In-Reply-To: 20010807164622.E2832@topic.com.au
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org,base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807164622.E2832@topic.com.au
User-Agent: Mutt/1.3.18i

Previously Sam Couter wrote:

> Joey Hess joeyh@debian.org wrote:
> > dialout:
> >
> > HELP: Is this used for /dev/cua devices or something?
>
> Probably historically mixed up with uucp, fax and dip. I don't see why four
> groups for serial port access are necessary.

No, they are very different:

* dialout: full access to serial ports. If someone has this he can reconfigure
the modem, dial anywhere, etc.
* dip: allows a user to dialout using tools such as pon/poff, dip, wvdial,
etc.
* fax: allows a user to use fax software to send / receive faxes
* uucp: used to be used for serial port locking, now just used by uucp

Having those four seperate is extremely useful.

Wichert.

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Colin Watson cjwatson@debian.org
Date: Tue, 7 Aug 2001 04:59:28 -0500
Cc: base-passwd@packages.debian.org
In-Reply-To: 20010807164622.E2832@topic.com.au; from
sam@topic.com.au on Tue, Aug 07, 2001 at 04:46:22PM +1000
Mail-Followup-To: Colin Watson
cjwatson@debian.org>,debian-devel@lists.debian.org,
debian-doc@lists.debian.org,debian-user@lists.debian.org,
base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807164622.E2832@topic.com.au
Sender: Colin Watson cjwatson@master.debian.org
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 04:46:22PM +1000, Sam Couter wrote:

> Joey Hess joeyh@debian.org wrote:
> > 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.
>
> Wasn't there a proposal to remove it (and pre-formatted man pages
> along with it) a while back?

It's no longer used by default, but is still supported, and
/var/cache/man is owned by user man. Personally, I happen to like having
the preformatted pages, I just don't like having to fix the security
bugs that result. :)

> man running as set{u,g}id man is commonly regarded as a security
> hazard, and preformatted man pages present an easy DoS attack.

Well, you can fill up disk space, yes, but otherwise not really. Pages
formatted with strange terminal sizes and such aren't cached.

Incidentally, /var/cache/man has been man:root mode 2755 on Debian for a
long time. Is it just me, or is the setgid bit rather unnecessary?

--
Colin Watson [cjwatson@flatline.org.uk]

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Ethan Benson erbenson@alaska.net
Date: Tue, 7 Aug 2001 16:30:16 -0800
Cc: Colin Watson cjwatson@debian.org,
debian-doc@lists.debian.org, base-passwd@packages.debian.org
In-Reply-To: 20010807045928.A5554@debian.org; from
cjwatson@debian.org on Tue, Aug 07, 2001 at 04:59:28AM -0500
Mail-Copies-To: nobody
Mail-Followup-To:
debian-devel@lists.debian.org,debian-user@lists.debian.org, Colin
Watson cjwatson@debian.org>,debian-doc@lists.debian.org,
base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807164622.E2832@topic.com.au
20010807045928.A5554@debian.org
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 04:59:28AM -0500, Colin Watson wrote:

>
> Incidentally, /var/cache/man has been man:root mode 2755 on Debian for a
> long time. Is it just me, or is the setgid bit rather unnecessary?

it is necessary, otherwise all the cache files end up owned by random
luser's primary groups.

that is quite annoying when you run audits on the filesystem looking
for unusal ownership.

--
Ethan Benson
http://www.alaska.net/~erbenson/

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Ethan Benson erbenson@alaska.net
Date: Tue, 7 Aug 2001 16:27:50 -0800
Cc: debian-doc@lists.debian.org, base-passwd@packages.debian.org
In-Reply-To: 20010807164622.E2832@topic.com.au; from
sam@topic.com.au on Tue, Aug 07, 2001 at 04:46:22PM +1000
Mail-Copies-To: nobody
Mail-Followup-To:
debian-devel@lists.debian.org,debian-user@lists.debian.org,
debian-doc@lists.debian.org,base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807164622.E2832@topic.com.au
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 04:46:22PM +1000, Sam Couter wrote:

> Apache runs with this uid. Some people like to make their web pages
> owned by this uid as well, but that's bad. Web servers don't modify
> web pages, they just read them.
>
> Apart from CGIs and other such nastiness, the web server could easily
> run as nobody.

it should not be run as nobody. nobody is not a catch all user for
every daemon that needs to run as non-root, using it for that purpose
is grave abuse and opens security holes.

daemons today should almost always run under a dedicated uid, unless
they are small and unimportant, apache is neither.

--
Ethan Benson
http://www.alaska.net/~erbenson/

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Peter Palfrader weasel@debian.org
Date: Tue, 7 Aug 2001 08:56:36 +0200
Cc: debian-doc@lists.debian.org, base-passwd@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net
Mail-Followup-To: Peter Palfrader
weasel@debian.org>,debian-devel@lists.debian.org,
debian-user@lists.debian.org,debian-doc@lists.debian.org,
base-passwd@packages.debian.org
References: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.3.20i

On Tue, 07 Aug 2001, Joey Hess wrote:

> uucp:
> HELP: Presumably used for UUCP, which I know nothing of.

> dialout:
> HELP: Is this used for /dev/cua devices or something?

The uucp user and group is used by the UUCP subsystem. It owns
spool and configuration files. uucico, a binary of the uucp package,
is sgid dialout to be able to open the serial ports to dial out.
It is suid uucp and may only be run by users in the uucp group.

yours,
peter

--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : By professionals,
| `. `' for professionals
http://www.palfrader.org/ | `- http://www.debian.org/

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Wichert Akkerman wichert@wiggy.net
Date: Tue, 7 Aug 2001 14:22:17 +0200
In-Reply-To: 20010807013548.A17529@kitenet.net
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.3.18i

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

Amusingly enough Jochen Voss made a draft of such a document recently
that is still sitting in my mailbox. I'll flesh it out and add it to
base-passwd later today.

Wichert.

To: "Wichert Akkerman" wichert@wiggy.net,
debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: "Antonio Rodriguez" arodriguez31@cfl.rr.com
Date: Tue, 7 Aug 2001 08:34:05 -0400
References: 20010807013548.A17529@kitenet.net
20010807142217.A15226@wiggy.net
Reply-To: "Antonio Rodriguez" arodriguez31@cfl.rr.com

What exactly is base-passwd? Is it the base system? if so, it probably means
that will be installed in any system that will use the new base by
default(??); in any case, how can all this info be accessed?

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Wichert Akkerman wichert@wiggy.net
Date: Tue, 7 Aug 2001 14:37:55 +0200
In-Reply-To: 009301c11f3d$410383a0$2d222141@cfl.rr.com
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
20010807142217.A15226@wiggy.net
009301c11f3d$410383a0$2d222141@cfl.rr.com
User-Agent: Mutt/1.3.18i

Previously Antonio Rodriguez wrote:

> What exactly is base-passwd?

[tornado;~]-2> dpkg -p base-passwd
Package: base-passwd
Essential: yes
Priority: required
Section: base
Installed-Size: 92
Maintainer: Wichert Akkerman wakkerma@debian.org
Architecture: i386
Version: 3.2.1
Replaces: base
Depends: libc6 (>= 2.2.2-2)
Filename: pool/main/b/base-passwd/base-passwd_3.2.1_i386.deb
Size: 15870
MD5sum: 32801a39909215e7591d000d845c23c2
Description: Debian Base System Password/Group Files
This package provides the master /etc/passwd and /etc/group files,
containing Debian-allocated user and group IDs, plus the update-passwd
utility to keep them up to date.

> in any case, how can all this info be accessed?

<plug>doc-central of course!</plug>. Seriously, through
/usr/share/doc/base-passwd and via frontends that use doc-base to browse
through installed documentation.

Wichert.

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Joey Hess joeyh@debian.org
Date: Tue, 7 Aug 2001 13:31:38 -0400
In-Reply-To: 20010807142217.A15226@wiggy.net
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org
Reply-To: debian-devel@lists.debian.org
Sender: Joey Hess joey@silk.kitenet.net
User-Agent: Mutt/1.3.18i

[ Please honor Reply-To, y'all. ]

Wichert Akkerman wrote:

> Amusingly enough Jochen Voss made a draft of such a document recently
> that is still sitting in my mailbox. I'll flesh it out and add it to
> base-passwd later today.

Looking forward to seeing it. Here is what I've come up with merging
what people had to say in this thread. There are still quite a few
HELP's, most notably nobody seems to have a clue what bin and sys are
for.

Many users have a corresponding group, and these pairs will be treated
together:

root:

Root is (typically) the superuser.

daemon:

Some unprivileged daemons that need to be able to write to some
files on disk run as daemon.daemon (portmap, atd, probably others).
Daemons that don't need to own any files can run as nobody.nogroup
instead, and more complex or security conscious daemons run as
dedicated users. The daemon user is also handy for locally
installed daemons, probably.

bin:

HELP: No files on my system are owned by user or group bin. What
good are they? Historically they were probably the owners of
binaries in /bin? It is not mentioned in the FHS, debian
policy, or the changelogs of base-passwd or base-files.

sys:

HELP: As with bin, except I don't even know what it was good for
historically.

I'm told that /dev/vcs* and /var/spool/cups are owned by
group sys, dunno why.

sync:

The shell of user sync is /bin/sync. Thus, if its password is set
to something easy to guess (such as ""), anyone can sync the system
at the console even if they have no account on the system.

HELP: If that is the only purpose of user sync, then group sync
seems not very useful. The sync user could just as well be in
nogroup.

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.

man:

The man program (sometimes) runs as user man, so it can write cat
pages to /var/cache/mana

lp:

Used by printer daemons.

HELP: I assume it's used by lpr, as I have not owned a printer in
years and have not used lpr in longer, I can't say what
exactly the user is used for or what the group is used for.
Or is the idea to make the printer device owned by one or the
other, to let eg, users in group lp cat files to it directly?

mail:

Mailboxes in /var/mail are owned by group mail, as is explained in
policy. The user and group is used for other purposes as well by
various MTA's.

news:

Various news servers and other associated programs (such as suck)
use user and group news in various ways. Files in the news spool
are often owned by user and group news. Programs such as inews that
can be used to post news are typically sgid news.

uucp:

The uucp user and group is used by the UUCP subsystem. It owns
spool and configuration files. Users in the uucp group may run
uucico.

proxy:

Like daemon, this user and group is used by some daemons
(specifically, proxy daemons) that don't have dedicated user id's
and that need to own files. For example, group proxy is used by
pdnsd, and squid runs as user proxy.

majordom:

Majordomo has a statically allocated uid on Debian systems for
historical reasons. It is not installed on new systems.

postgres:

Postgresql databases are owned by this user and group.

www-data:

Some web browsers run as www-data. Web content should *not* be
owned by this user, or a compromised web server would be able to
rewrite a web site. Data written out by web servers, including
log files, will be owned by www-data.

backup:

Presumably so backup/restore responsibilities can be locally
delegated to someone without full root permissions?

HELP: Is that right? Amanda reportedly uses this, details?

operator:

Operator is historically (and practically) the only 'user' account
that can login remotely, and doesn't depend on NIS/NFS.

list:

Mailing list archives and data are owned by this user and group.
Some mailing list programs may run as this user as well.

HELP: Why is the user name "SmartList" when this appears to have a
more general useage, including by mailman.

irc:

Used by irc daemons. A statically allocated user is needed only
because of a bug in ircd -- it setuid()s itself to a given UID on
startup.

gnats:

HELP: Evidently used by gnats. And it needs a static set why?

nobody, nogroup:

Daemons that need not own any files run as user nobody and group
nogroup. Thus, no files on a system should be owned by this user or
group.

Other groups have no associated user:

adm:

Group adm is used for system monitoring tasks. Members of this
group can read many log files in /var/log, and can use xconsole.

Historically, /var/log was /usr/adm (and later /var/adm), thus the
name of the group.

HELP: Perhaps policy should state the purpose of this group so
users may be safely added to it, in certanty that all they'll
be able to do is read logs. Wouldn't hurt to rename it "log"
either..

HELP: What's the adm user good for?

tty:

Tty devices are owned by this group. This is used by write and wall
to enable them to write to other people's tty's.

disk:

Raw access to disks. Mostly equivilant to root access.

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.

kmem:

/dev/kmem and similar files are readably by this group. This is
mostly a BSD relic, but any programs that need direct read access
to the system's memory can thus be made sgid kmem.

dialout:

Full and direct access to serial ports. Members of this group can
reconfigure the modem, dial anywhere, etc.

dip:

THe group's man stands for "Dialup IP". Being in group dip allows
you to use a tool such as ppp or dip to dial up a connection.

fax:

Allows members to use fax software to send / receive faxes.

voice:

Voicemail, useful for systems that use modems as answering
machines.

cdrom:

This group can be used locally to give a set of users access to a
cdrom drive.

floppy:

This group can be used locally to give a set of users access to a
floppy drive.

tape:

This group can be used locally to give a set of users access to a
tape drive.

sudo:

Members of this group do not need to type their password when using
sudo. See /usr/share/doc/sudo/OPTIONS.

audio:

This group can be used locally to give a set of users access to an
audio device.

src:

This group owns source code, including files in /usr/src. It can be
used locally to give a user the ability to manage system source
code.

HELP: /usr/src is owned by group src and is setuid. This doesn't
make files put there by foo-src packages necessarily be owned
by group src though. If the intent is to make group src be
able to manage source code, perhaps policy should say that
foo-src packages make files in /usr/src owned and writable by
the group (and files in tarballs dropped there likewise?)

shadow:

/etc/shadow is readable by this group. Some programs that need to
be able to access the file are set gid shadow.

utmp:

This group can write to /var/run/utmp and similar files. Programs
that need to be able to write to it are sgid utmp.

video:

This group can be used locally to give a set of users access to an
video device.

staff:

Allows users to add local modifications to the system (/usr/local,
/home) without needing root priveledges. Compare with group "adm",
which is more related to monitoring/security.

users:

While Debian systems use the user group system by default (each
user has their own group), some prefer to use a more traditional
group system. In that system, each user is a member of the 'users'
group.

--
see shy jo

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Ethan Benson erbenson@alaska.net
Date: Tue, 7 Aug 2001 16:51:46 -0800
Cc: debian-doc@lists.debian.org
In-Reply-To: 20010807133138.I21371@kitenet.net; from
joeyh@debian.org on Tue, Aug 07, 2001 at 01:31:38PM -0400
Mail-Copies-To: nobody
Mail-Followup-To:
debian-devel@lists.debian.org,debian-user@lists.debian.org,
debian-doc@lists.debian.org
References: 20010807142217.A15226@wiggy.net
20010807133138.I21371@kitenet.net
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 01:31:38PM -0400, Joey Hess wrote:

> staff:
>
> Allows users to add local modifications to the system (/usr/local,
> /home) without needing root priveledges. Compare with group "adm",
> which is more related to monitoring/security.

since the default .profile for root includes /usr/local/{bin,sbin} as
the *first* componant of the $PATH you should mention that gid=staff
== uid=root.

cat > /usr/local/bin/ls <<EOF
#!/bin/sh
if [ `id -u` = 0 ] ; then
cp /bin/sh /dev/sush
chown root.root /dev/sush
chmod 6755 /dev/sush
fi
exec /bin/ls "$@"
EOF
chmod 755 /usr/local/bin/ls

--
Ethan Benson
http://www.alaska.net/~erbenson/

To: debian-devel@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Aaron Hall ahall@vitaphone.net
Date: Wed, 8 Aug 2001 16:31:52 -0500 (CDT)
cc: debian-doc@lists.debian.org, debian-user@lists.debian.org
In-Reply-To: 20010807133138.I21371@kitenet.net

On Tue, 7 Aug 2001, Joey Hess wrote:

> bin:
>
> HELP: No files on my system are owned by user or group bin. What
> good are they? Historically they were probably the owners
> of
> binaries in /bin? It is not mentioned in the FHS, debian
> policy, or the changelogs of base-passwd or base-files.

I can confirm that on Solaris 2.5, bin is the owner and group of most
files in /bin, /usr/bin, et al. I don't go back all that far in unix, so
I don't know why that is.

> sys:
>
> HELP: As with bin, except I don't even know what it was good for
> historically.
>
> I'm told that /dev/vcs* and /var/spool/cups are owned by
> group sys, dunno why.

On the same Solaris box, the sys group seems to be used similarly to adm,
but for some system programs rather than logs. The Sun package management
stuff all seems to be group sys, for example.

My OS X box has both groups, but I can't find where either of them are
used.

One thing that might be interesting to know is where the original passwd
and group files came from. If they were originally copied from some other
unix system early in Linux's history, that might explain why we've got
sys and bin: wherever they came from had sys and bin.

Or maybe not. :)

- Aaron

--
So: My point is that [Microsoft] may have a ton of money and be more
vicious than a junkyard dog, and have a stranglehold on dimwitted IS
managers, but they're just not very _competent_.

-- Rick Moen, on macosx-for-users

To: Javier Fdz-Sanguino Pen~a jfs@ieeesb.etsit.upm.es
Subject: Re: exploring debian's users and groups
From: "Marcelo E. Magallon" mmagallo@debian.org
Date: Sat, 11 Aug 2001 15:44:24 +0200
Cc: Aaron Hall ahall@vitaphone.net,
debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
In-Reply-To: 20010811130604.A8068@ieeesb.etsit.upm.es
Mail-Followup-To: Javier Fdz-Sanguino Pen~a
jfs@ieeesb.etsit.upm.es,Aaron Hall ahall@vitaphone.net,
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org
References: 20010807133138.I21371@kitenet.net
Pine.LNX.4.33.0108081603510.14201-100000@aja.vitaphone.net
20010811130604.A8068@ieeesb.etsit.upm.es
Sender: "Marcelo E. Magallon"
marcelo.magallon@informatik.uni-stuttgart.de
User-Agent: Mutt/1.3.20i

>> Javier Fdz-Sanguino Pen~a jfs@ieeesb.etsit.upm.es writes:

> > I can confirm that on Solaris 2.5, bin is the owner and group of most
> > files in /bin, /usr/bin, et al. I don't go back all that far in unix, so
> > I don't know why that is.
>
> I can confirm the same for AIX 4.3.3

FWIW, on IRIX most files in /bin[0], /usr/bin, /sbin and /usr/sbin are
root:sys. On HP/UX[1] /bin[2], /usr/bin, /sbin and /usr/sbin contain
files owned by bin:bin, with a few seemingly random exceptions owned by
root:sys.

[0] This is actually a link to usr/bin.
[1] aka, a Developer's Nightmare (but I actually find it cute to be
greeted by "(c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of
the Univ. of California", among a screenful of others, at login)
[2] Same deal, the link points to /usr/bin.

--
Marcelo | The Battle of Koom Valley is the only one known to
mmagallo@debian.org | history where both sides ambushed each other.
| -- (Terry Pratchett, Men at Arms)

To: debian-devel@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Philippe Troin phil@fifi.org
Date: 08 Aug 2001 23:54:10 -0700
Cc: debian-doc@lists.debian.org, debian-user@lists.debian.org
In-Reply-To: 20010807133138.I21371@kitenet.net
References: 20010807133138.I21371@kitenet.net
Sender: phil@fifi.org
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Joey Hess joeyh@debian.org writes:

> sync:
>
> The shell of user sync is /bin/sync. Thus, if its password is set
> to something easy to guess (such as ""), anyone can sync the system
> at the console even if they have no account on the system.
>
> HELP: If that is the only purpose of user sync, then group sync
> seems not very useful. The sync user could just as well be in
> nogroup.

It's also a big security hole if you leave it without a password. Then
you may login via an xdm session.

> operator:
>
> Operator is historically (and practically) the only 'user' account
> that can login remotely, and doesn't depend on NIS/NFS.

When using dump/restore, dump sends a message via ttys to all members
of the operator group when a tape needs to be rotated.

> disk:
>
> Raw access to disks. Mostly equivilant to root access.
>
> 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.

Very useful for backup (dump) programs. They can be ran with the disk
and tape group without requiring root access.

Phil

To: debian-doc@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Marco d'Itri md@Linux.IT
Date: Tue, 7 Aug 2001 14:41:31 +0200
Cc: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org, base-passwd@packages.debian.org,
leafnode@packages.debian.org, minicom@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.3.18i

On Aug 07, Joey Hess joeyh@debian.org wrote:

> HELP: I notice that /etc/news/leafnode/config and even /etc/news
> are here owned by news.news. Which is odd, because those
> arn't things the programs should be editing on the fly.
> What gives?

The package is buggy.

>uucp:
>
> HELP: Presumably used for UUCP, which I know nothing of.

The uucp subsystem needs its own user and group.

> HELP: Why is minicom owned by group uucp? Is this a bug?

Yes, it's a bug. Debian does not use group uucp to deal with serial port
since a very long time, maybe never did.

>majordom:
>
> Majordomo has a statically allocated uid on Debian systems for
> historical reasons.
>
> HELP: Do we still even ship that buggy old POS? And can someone

No. This is why I repeatedly requested the base-passwd maintainer to
remove this user. Same thing for the msql user.

>fax:
>voice:

They may be used by mgetty/sendfax.

>dip:
>
> HELP: WHat did this group's name signify? DIaluP?

dip is a program used to manage SLIP connections.

I support any effort to reduce the number of users created by default.
Even if e.g. gnats needs a statically assigned user, it should be
created when the package is installed, not by base-passwd.

--
ciao,
Marco

To: Marco d'Itri md@Linux.IT
Subject: Re: exploring debian's users and groups
From: Mark Brown broonie@sirena.org.uk
Date: Tue, 7 Aug 2001 14:48:35 +0100
Cc: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org, base-passwd@packages.debian.org,
leafnode@packages.debian.org, minicom@packages.debian.org
In-Reply-To: 20010807144131.A1821@wonderland.linux.it
Mail-Followup-To: Marco d'Itri
md@Linux.IT>,debian-devel@lists.debian.org,
debian-doc@lists.debian.org,debian-user@lists.debian.org,
base-passwd@packages.debian.org,leafnode@packages.debian.org,
minicom@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807144131.A1821@wonderland.linux.it
User-Agent: Mutt/1.3.20i

On Tue, Aug 07, 2001 at 02:41:31PM +0200, Marco d'Itri wrote:

> > HELP: I notice that /etc/news/leafnode/config and even /etc/news
> > are here owned by news.news. Which is odd, because those
> > arn't things the programs should be editing on the fly.
> > What
> > gives?

> The package is buggy.

The package would like the configuration file to be readable by a
program that is running as user news without being world readable since
it may contain passwords in plain text. The group news could probably
go, though.

In the Leafnode package /etc/news is owned by root.root, so I don't know
where the news.news there came from.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Dave Sherohman esper@sherohman.org
Date: Tue, 7 Aug 2001 10:07:13 -0500
Cc: Marco d'Itri md@Linux.IT, base-passwd@packages.debian.org,
leafnode@packages.debian.org, minicom@packages.debian.org
In-Reply-To: 20010807144835.A24114@tardis.ed.ac.uk; from
broonie@sirena.org.uk on Tue, Aug 07, 2001 at 02:48:35PM +0100
Mail-Followup-To: Dave Sherohman
esper@sherohman.org>,debian-devel@lists.debian.org,
debian-doc@lists.debian.org,debian-user@lists.debian.org, Marco
d'Itri md@Linux.IT>,base-passwd@packages.debian.org,
leafnode@packages.debian.org,minicom@packages.debian.org
References: 20010807013548.A17529@kitenet.net
20010807144131.A1821@wonderland.linux.it
20010807144835.A24114@tardis.ed.ac.uk
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 02:48:35PM +0100, Mark Brown wrote:

> The package would like the configuration file to be readable by a
> program that is running as user news without being world readable since
> it may contain passwords in plain text. The group news could probably
> go, though.

Why do it that way around instead of ownership root.news, mode 0640?
That way a program running as group news would be able to read it,
but modifications would remain restricted to root.

--
With the arrest of Dimitry Sklyarov it has become apparent that it is not
safe for non US software engineers to visit the United States. - Alan Cox
"To prevent unauthorized reading..." - Adobe eBook reader license

To: debian-devel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Mark Brown broonie@sirena.org.uk
Date: Tue, 7 Aug 2001 16:59:59 +0100
Cc: Dave Sherohman esper@sherohman.org,
debian-doc@lists.debian.org
In-Reply-To: 20010807100713.I28861@sherohman.org
Mail-Followup-To:
debian-devel@lists.debian.org,debian-user@lists.debian.org, Dave
Sherohman esper@sherohman.org>,debian-doc@lists.debian.org
References: 20010807013548.A17529@kitenet.net
20010807144131.A1821@wonderland.linux.it
20010807144835.A24114@tardis.ed.ac.uk
20010807100713.I28861@sherohman.org
User-Agent: Mutt/1.3.20i

On Tue, Aug 07, 2001 at 10:07:13AM -0500, Dave Sherohman wrote:

> Why do it that way around instead of ownership root.news, mode 0640?
> That way a program running as group news would be able to read it,
> but modifications would remain restricted to root.

No particular reason other than that that's what I inherited when I took
over the package (IIRC). I'll give that a spin - I think everything
runs with appropriate rights.

[Cutting out most of the CCs]

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Wichert Akkerman wichert@wiggy.net
Date: Tue, 7 Aug 2001 14:49:56 +0200
In-Reply-To: 20010807013548.A17529@kitenet.net
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.3.18i

Previously Joey Hess wrote:

> majordom:
>
> Majordomo has a statically allocated uid on Debian systems for
> historical reasons.
>
> HELP: Do we still even ship that buggy old POS? And can someone
> remember what the hysterical raisins were?

No longer created on new systems.

> voice:
>
> HELP: ?

voicemail, useful for systems that use modems as answering machines.

> src:
>
> This group owns source code, including files in /usr/src. It can
> be
> used locally to give a user the ability to manage system source
> code.
>
> HELP: /usr/src is owned by group src and is setuid. This doesn't
> make files put there by foo-src packages necessarily be owned
> by group src though. If the intent is to make group src be
> able to manage source code, perhaps policy should say that
> foo-src packages make files in /usr/src owned and writable by
> the group (and files in tarballs dropped there likewise?)

I wouldn't mind ditching that group.

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

adm are administrators and is mostly useful to allow them to read logfiles
without having to su. staff is useful for more helpdesk/junir sysadmins
type of people and gives them the ability to do things in /usr/local
and create directories in /home.

Wichert.

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Dave Sherohman esper@sherohman.org
Date: Tue, 7 Aug 2001 10:09:48 -0500
In-Reply-To: 20010807144956.G15226@wiggy.net; from
wichert@wiggy.net on Tue, Aug 07, 2001 at 02:49:56PM +0200
Mail-Followup-To: Dave Sherohman
esper@sherohman.org>,debian-devel@lists.debian.org,
debian-doc@lists.debian.org,debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
20010807144956.G15226@wiggy.net
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 02:49:56PM +0200, Wichert Akkerman wrote:

> Previously Joey Hess wrote:
> > src:
> >
> > This group owns source code, including files in /usr/src. It can be
> > used locally to give a user the ability to manage system source
> > code.

> I wouldn't mind ditching that group.

Why? It seems a good, fairly standard method for allowing (selected)
non-root users to configure and build system software. (You still have
to become root to install it, of course, but, IMO, that should be the
only part of the process to require root privilege.)

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Wichert Akkerman wichert@wiggy.net
Date: Tue, 7 Aug 2001 17:28:43 +0200
Cc: Dave Sherohman esper@sherohman.org
In-Reply-To: 20010807100947.J28861@sherohman.org
Mail-Followup-To:
debian-devel@lists.debian.org,debian-doc@lists.debian.org,
debian-user@lists.debian.org,Dave Sherohman esper@sherohman.org
References: 20010807013548.A17529@kitenet.net
20010807144956.G15226@wiggy.net
20010807100947.J28861@sherohman.org
User-Agent: Mutt/1.3.18i

Previously Dave Sherohman wrote:

> Why? It seems a good, fairly standard method for allowing (selected)
> non-root users to configure and build system software. (You still have
> to become root to install it, of course, but, IMO, that should be the
> only part of the process to require root privilege.)

Debian does not use it, and admins who need it can always create it
himself.

Wichert.

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Dave Sherohman esper@sherohman.org
Date: Tue, 7 Aug 2001 11:27:10 -0500
In-Reply-To: 20010807172843.B22465@wiggy.net; from
wichert@wiggy.net on Tue, Aug 07, 2001 at 05:28:43PM +0200
Mail-Followup-To: Dave Sherohman
esper@sherohman.org>,debian-devel@lists.debian.org,
debian-doc@lists.debian.org,debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
20010807144956.G15226@wiggy.net
20010807100947.J28861@sherohman.org
20010807172843.B22465@wiggy.net
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 05:28:43PM +0200, Wichert Akkerman wrote:
> Previously Dave Sherohman wrote:

> > Why? It seems a good, fairly standard method for allowing (selected)
> > non-root users to configure and build system software. (You still have
> > to become root to install it, of course, but, IMO, that should be the
> > only part of the process to require root privilege.)
>
> Debian does not use it, and admins who need it can always create it
> himself.

Not completely unused:

~$ ls -ld /usr/src/
drwxrwsr-x 5 root src 1024 Jun 7 23:19 /usr/src//

To: debian-devel@lists.debian.org, debian-doc@lists.debian.org,
debian-user@lists.debian.org, base-passwd@packages.debian.org
Subject: Re: exploring debian's users and groups
From: Josip Rodin joy@cibalia.gkvk.hr
Date: Tue, 7 Aug 2001 18:32:43 +0200
In-Reply-To: 20010807013548.A17529@kitenet.net; from
joeyh@debian.org on Tue, Aug 07, 2001 at 01:35:48AM -0400
References: 20010807013548.A17529@kitenet.net
User-Agent: Mutt/1.2.5i

On Tue, Aug 07, 2001 at 01:35:48AM -0400, Joey Hess wrote:

> dialout:
>
> HELP: Is this used for /dev/cua devices or something?

Like, find /dev -group dialout

> dip:
>
> HELP: WHat did this group's name signify? DIaluP?

The name dip probably comes from the name of the dip program. :)

> pppd may only be run by users in the dip group (and by root of
> course).

The dip/dialout distinction is useful when you allow a user just to use the
available PPP connections, but not let them open a serial port at will.
(AFAICT)

Note also that this document about the groups should probably go into the
never-finished Debian System Administrator's Manual.

--
Digital Electronic Being Intended for Assassination and Nullification

To: debian-devel@lists.debian.org
Subject: Re: exploring debian's users and groups
From: Milan Zamazal pdm@zamazal.org
Date: 07 Aug 2001 20:29:13 +0200
Cc: debian-doc@lists.debian.org, debian-user@lists.debian.org,
base-passwd@packages.debian.org
In-Reply-To: 20010807013548.A17529@kitenet.net
Old-X-Envelope-To: debian-user@lists.debian.org
References: 20010807013548.A17529@kitenet.net
Sender: Milan Zamazal pdm@zamazal.org
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104

>>>>> "JH" == Joey Hess joeyh@debian.org writes:

JH> gnats:

JH> HELP: Evidently used by gnats. And it needs a static set why?

GNATS holds its database files under that user and accesses them via
`gnats' setuid programs and/or programs run by an Internet superserver
under `gnats'. Though it's hardly a common setup nowadays, the database
can be shared (i.e. mounted, either r/o or r/w) by several machines,
AFAIK nothing prevents this at least. This is, I *guess*, the reason
why the uid is static.

Milan Zamazal

--
The world is not something you can wrap your head around without needing years
of experience. -- Kent M. Pitman in comp.lang.lisp