On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote: > On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a > wrote: > > > That really depends on the daemon itself don't you think? There's a number > > of > > daemons that don't create any file at all or, if they do, are created > > only on a given directory which is removed on purge. In these cases, > > removing > > the user on postrm's purge might make sense. As I said, that would be an > > option. > > It is still possible that those daemons _read_ some files (e.g. config > files), and the admin did a chown/chgrp to the daemon's user. Removing > the user and reusing the UID/GID will suddenly make those files > accessible for a random new package which may not be intended at all.
Wrong. That is only true in the chown() case. Which is not a sensible thing to do. Daemons should be able to read their configuration files but they usually *don't* need to *write* them, so they should *not* own them. The reasoning for this is that if a security vulnerability is found that affects the daemon, and it can write to its configuration file, then you are introducing additional risks beyond the vulnerability itself. Think for example: - a chrooted() FTP server that can write to its configuration files or to the applications in the chroot - a web server that can write in its web page space area. - a SSH server that can write to sshd_config (and, consequently, can enable subsystems, authentication methods or remove limitations set by the admin) If you find daemons which have their configuration files chown'ed to them withouth there being a need to write to, please file a bug. Now, baring the chown() case, you have two think of two type of configuration files: those that hold sensitive information and those that do not. If they don't hold sensitive information then you make those world readable, if they do then you use a group, which can be shared by different packages or used by only one package. Here's an analysis of different situations for configuration files under those premises: [ File with sensitive information ] - File is mode 640 and owned by root - File belongs to the 'X' group, if the group is shared across packages then the group should not be removed (or created) by the daemon package. - Daemon 'D' belongs to the 'X' group, so he can read the file Removal consequence: none. ¿Why? if the file is *not* shared across packages, both the user, the group and the file should be removed _at_the_same_ time on purge. If the file is shared across packages (and is not a configuration file of the daemon package), removal (or purge) of the daemon cannot lead to the removal of the shared group. In either case, the file is not orphaned. ¿Can a new system daemon read the file?: no, unless he is added to the 'X' group. [ File without sensitive information ] - File is mode 644 and owned by root, and belongs to 'root' group or any other generic group ('adm') - Daemon 'D' can read the file (due to it being world-readable) Removal consequence: none, the file does not belong to the daemon user or its group in any way, so it being remove cannot orphan the file. ¿Can a new system daemon read the file? Of course, the file is mode 644 The only situation where removing a daemon user is an issue is when the files have either: a- been created by the daemon through its normal operation b- been created by the root user when impersonating the daemon If the files hold to a) and are _not_ configuration files, log files, or state files (i.e. under /var/run/, /var/state/, etc.) which should be removed on purge as defined per policy, then the daemon should *not* be removed on purge. This is the case of, for example, an MTA, which will create queue files and spool files in normal operation. If all the files in a) are purged and only b) remains as a possibility then have the admin make a decission (and default to 'yes, remove' if appropiate) Regards Javier
signature.asc
Description: Digital signature