|
|
发表于 2005-4-8 12:37:04
|
显示全部楼层
- 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, jabberd, lambdamoo, mon, and
- others). Daemons that don't need to own any files sometimes run as
- nobody.nogroup instead; it is generally better practice to use a dedicated
- user, and more complex or security-conscious daemons certainly do this. The
- daemon user is also handy for locally installed daemons, probably.
- LSB 1.3 lists daemon as legacy, and says: "The 'daemon' UID/GID was used as
- an unprivileged UID/GID for daemons to execute under in order to limit
- their access to the system. Generally daemons should now run under
- individual UID/GIDs in order to further partition daemons from one
- another."
- 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.
- LSB 1.3 lists bin as legacy, and says: "The 'bin' UID/GID is included for
- compatibility with legacy applications. New applications should no longer
- use the 'bin' UID/GID."
- sys
- HELP: As with bin, except I don't even know what it was good for
- historically.
- I'm told that /var/spool/cups is 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.
- games
- Many games are sgid to games so they can write their high score files. This
- is explained in Debian Policy.
- man
- The man program (sometimes) runs as user man, so it can write cat pages to
- /var/cache/man and update its databases there.
- lp
- The lp* devices are writable by this group so that users in it can access
- the parallel ports directly. Traditionally this job is taken by a printer
- daemon instead which will only need to run in this group.
- The lpr system keeps its spool directories owned by lp/lp. Its daemon and
- frontend tools (through setuid) run as user root.
- HELP: what do other print systems (rlpr, cupsys, lprng, ...) do?
- mail
- Mailboxes in /var/mail are owned and writeable by group mail, as is
- explained in Debian Policy. The user and group is used for other purposes
- as well by various MTAs and MUAs.
- 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 ids 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 servers 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
- Historically, the operator user account was used by system operators with
- low privilege to dump filesystem backups to tape, and was in the root group
- so that it could do this. In Debian, the use of a utility such as sudo to
- gain privilege is preferred over such highly-special-purpose accounts, and
- the operator user is no longer created by default. It had uid 37.
- The operator group is used by dump -n to notify logged-in operators via
- wall when it requires operator attention. This is a historical use, and new
- applications should not behave this way. (If nothing else, the group should
- be configurable.)
- list
- Mailing list archives and data are owned by this user and group. Some
- mailing list programs may run as this user as well.
- irc
- Used by IRC daemons. A statically allocated user is needed only because of
- a bug in ircd: it setuid()s itself to a compiled-in user id on startup.
- gnats
- HELP: Evidently used by gnats. And it needs a static set why?
- nobody, nogroup
- Daemons that need not own any files sometimes run as user nobody and group
- nogroup, although using a dedicated user is far preferable. Thus, no files
- on a system should be owned by this user or group.
- (Technically speaking, it does no harm for a file to be owned by group
- nogroup as long as the ownership confers no additional privileges, that is
- if the group and other permission bits are equal. However, this is sloppy
- practice and should be avoided.)
- If root-squashing is in use over NFS, root access from the client is
- performed as user nobody on the server.
- 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 certainty that all they'll be able to do is read
- logs. Wouldn't hurt to rename it 'log' either ...
- tty
- Tty devices and /dev/vcs* are owned by this group. This is used by write
- and wall to enable them to write to other people's ttys.
- disk
- Raw access to disks. Mostly equivalent 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 readable 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 setgid kmem.
- dialout
- Full and direct access to serial ports. Members of this group can
- reconfigure the modem, dial anywhere, etc.
- dip
- The group's name 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 or 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 CD-ROM
- 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 setgid. 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
- writeable 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 setgid shadow.
- utmp
- This group can write to /var/run/utmp, /var/log/wtmp, /var/log/lastlog, and
- similar files. Programs that need to be able to write to them (such as X
- terminal emulators) are setgid utmp.
- video
- This group can be used locally to give a set of users access to a video
- device.
- plugdev
- Members of this group can mount removable devices in limited ways via
- pmount without a matching entry in /etc/fstab. This is useful for local
- users who expect to be able to insert and use CDs, USB drives, and so on.
- Since pmount always mounts with the nodev and nosuid options and applies
- other checks, this group is not intended to be root-equivalent in the ways
- that the ability to mount filesystems might ordinarily allow. Implementors
- of semantics involving this group should be careful not to allow
- root-equivalence.
- staff
- Allows users to add local modifications to the system (/usr/local, /home)
- without needing root privileges. 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.
Debian中base-passwd文档中的部分内容，但各个发行版还是有些区别的。 |
|
IP卡
狗仔卡
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主