Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 01:31:38PM -0400, Joey Hess wrote: 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. boy this smells an awful lot like a good newbiedoc intro, doesn't it? hmm? right? (nice job so far -- these specific user/group concepts are something i've wondered about, myself, for quite some time!) -- DEBIAN NEWBIE TIP #45 from Will Trillich [EMAIL PROTECTED] : Troubled by DOS-FORMAT TEXT FILES? There are many ways to get rid of the extra ^M characters. In VIM, try :set ff=unix before saving the file (:opt for more info); or, use perl: perl -pi.dos -e 's/\cM//g' filename*pattern.txt (perldoc perlrun for more info.) Also see http://newbieDoc.sourceForge.net/ ...
Re: exploring debian's users and groups
On Wed, Aug 08, 2001 at 04:31:52PM -0500, Aaron Hall wrote: 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. I can confirm the same for AIX 4.3.3 Regards Javi
Re: exploring debian's users and groups
Javier Fdz-Sanguino Pen~a [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | history where both sides ambushed each other. | -- (Terry Pratchett, Men at Arms)
Re: exploring debian's users and groups
Javier Fdz-Sanguino Pen~a writes: I can confirm that on Solaris 2.5, bin is the owner and group of most files in /bin, /usr/bin, et al. Likewise on System III on my Onyx, IIRC. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: exploring debian's users and groups
Joey Hess [EMAIL PROTECTED] 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.
Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 05:46:31PM -0700, Eric G. Miller wrote: On Tue, Aug 07, 2001 at 12:25:56PM -0400, Joey Hess wrote: ... Hmm, I'm not sure I understand. Yes of course you have games owned by group games. But what is the user good for? Got me. I thought this allowed sgui-ed games to have a top-scores file that can't be altered by lusers, unless ofcourse they turn into winners. -- groetjes, carel
Re: exploring debian's users and groups
On Aug 07, Adam Heath [EMAIL PROTECTED] wrote: This is kinda like group mail. People can be added to group uucp, then be able to call the uucp binaries, to interact with the uucp subsystem. No user should be ever added to group uucp. -- ciao, Marco
Re: exploring debian's users and groups
On Wed, Aug 08, 2001 at 12:41:13PM +0200, Carel Fellinger wrote: On Tue, Aug 07, 2001 at 05:46:31PM -0700, Eric G. Miller wrote: On Tue, Aug 07, 2001 at 12:25:56PM -0400, Joey Hess wrote: ... Hmm, I'm not sure I understand. Yes of course you have games owned by group games. But what is the user good for? Got me. I thought this allowed sgui-ed games to have a top-scores file that can't be altered by lusers, unless ofcourse they turn into winners. Yep, that's what the group games is for. But why is there also a user games? -- 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
Re: exploring debian's users and groups
On Wed, Aug 08, 2001 at 09:43:36AM -0500, Dave Sherohman wrote: On Wed, Aug 08, 2001 at 12:41:13PM +0200, Carel Fellinger wrote: ... I thought this allowed sgui-ed games to have a top-scores file that can't be altered by lusers, unless ofcourse they turn into winners. Yep, that's what the group games is for. But why is there also a user games? Ah, sorry didn't read carrefully enough:) User games could be used as a generic user for games that need a server, like that tamagotchi beast, or a Go server. Don't know if it's used like that...checking...yes it is for tama(gotchi). -- groetjes, carel
Re: exploring debian's users and groups
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
exploring debian's users and groups
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 id's 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
Re: exploring debian's users and groups
(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.
Re: exploring debian's users and groups
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
Re: exploring debian's users and groups
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/ It would be nice if someone came up with a certification system that actually separated those who can barely regurgitate what they crammed over the last few weeks from those who command secret ninja networking powers.
Re: exploring debian's users and groups
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 -- KeyID=759975BD fingerprint=887A 4BE3 6AB7 EE3C 4AE0 B0E1 0556 E25A 7599 75BD
Re: exploring debian's users and groups
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
Re: exploring debian's users and groups
Joey Hess [EMAIL PROTECTED] 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/
[EMAIL PROTECTED]| tSA Consulting |
OpenPGP key ID: DE89C75C, available on key servers
OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
pgpb61pdNy5cr.pgp
Description: PGP signature
Re: exploring debian's users and groups
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/ pgpjjclhlLaeF.pgp Description: PGP signature
Re: exploring debian's users and groups
* Martijn van Oosterhout | 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. Used by mailman as well. -- Tollef Fog Heen You Can't Win
Re: exploring debian's users and groups
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 [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: exploring debian's users and groups
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 \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
Previously Sam Couter wrote: Joey Hess [EMAIL PROTECTED] 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. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 04:46:22PM +1000, Sam Couter wrote:
Joey Hess [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: exploring debian's users and groups
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. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
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? 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.
Re: exploring debian's users and groups
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 [EMAIL PROTECTED] 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? plugdoc-central of course!/plug. Seriously, through /usr/share/doc/base-passwd and via frontends that use doc-base to browse through installed documentation. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
On Aug 07, Joey Hess [EMAIL PROTECTED] 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
Re: exploring debian's users and groups
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. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
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 [EMAIL PROTECTED] Dept. of Computing, Imperial College, London, UK pgpWtM03TC5um.pgp Description: PGP signature
Re: exploring debian's users and groups
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.
Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 02:03:15PM +0100, Andrew Suffield wrote: 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. ircu has proven more or less crap anyway; IMHO ircd should be a virtual package provided by bahamut, hybrid, ircd and dancer-ircd. :) d -- Daniel Stone [EMAIL PROTECTED] Nuke can NE1 help me aim nuclear weaponz? /MSG ME!!
Re: exploring debian's users and groups
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
Re: exploring debian's users and groups
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.) -- 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
Re: exploring debian's users and groups
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. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: exploring debian's users and groups
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.
Re: exploring debian's users and groups
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-x5 root src 1024 Jun 7 23:19 /usr/src// -- 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
Re: exploring debian's users and groups
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
Re: exploring debian's users and groups
[ 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
Re: exploring debian's users and groups
JH == Joey Hess [EMAIL PROTECTED] 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
Re: exploring debian's users and groups
On Tue, 7 Aug 2001, 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? -- uucp: HELP: Presumably used for UUCP, which I know nothing of. This is kinda like group mail. People can be added to group uucp, then be able to call the uucp binaries, to interact with the uucp subsystem. uucp also has the ability to copy files(and run programs) between machines, and I think having it as a separate user gives a little more security. HELP: Why is minicom owned by group uucp? Is this a bug? I would think so. 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? majordomo is non-free. IMHO *NO* static user ids should be given to non-free 'POS'. postgres: HELP: Presumably used by the postgresql database? Security, to keep people from reading the database files. www-data: HELP: Er, I should know this, but this box doesn't run apache and I'm offline. No webfiles should be owned by www-data, as that is what httpd daemons run as. However, some cgi scripts(and the daemons themselves) need to write temp files, so they are given a separate user. dialout: HELP: Is this used for /dev/cua devices or something? cua devices are not used anymore. audio: This group can be used locally to give a set of users access to an audio device. ... video: This group can be used locally to give a set of users access to an video device. It has been discussed in the past, that audio is a poor name for this. We now have video, audio, mixer, joystick, cdrom, dvd(others). All are multi-media devices.
Re: exploring debian's users and groups
On Mon, Aug 06, 2001 at 11:02:53PM -0700, [EMAIL PROTECTED] wrote: 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. no, apache should run as www-data (as it does) but no files should be owned by this user. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJh8V0Mn4Qu.pgp Description: PGP signature
Re: exploring debian's users and groups
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/ pgpdAimq1NL73.pgp Description: PGP signature
Re: exploring debian's users and groups
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/ pgplNQRxoAcdI.pgp Description: PGP signature
Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 12:25:56PM -0400, Joey Hess wrote: 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? Got me. 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? Hmm, backups? -- Eric G. Miller egm2@jps.net
Re: exploring debian's users and groups
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/
pgpnL6arrH36f.pgp
Description: PGP signature
