On Wed, Oct 26, 2005 at 05:24:46PM +0200, Gabor Gombas wrote:
> On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Pe?a wrote:
>
> > 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.
>
> That is true in general, but I've seen it enough times to say it is a
> common administration mistake. Of course, you can say that if the admin
> wants to shoot himself on the foot, let's give him a bigger gun...
>
> > [ 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.
>
> Here you assume that the packaging system knows about all such files, but
> that is simply not true. Simple example: a daemon that is capable of
> TLS. Now, the admin generates a certificate/key pair, and modifies the
> config file to use them. At this point, the packaging system has _zero_
> knowledge that the cert/key files exist, so it can not remove them (and
> even parsing the config file to locate them would be wrong, since those
> files were generated by the admin therefore should never be removed by
> the package).
Correct, they should not be removed, but since configuration files should
reside in /etc, even better, in /etc/$daemon, it would just be a matter of
having a postrm test on purge that, once removed the conffiles from
the package, checks if there are files there and asks the admin on what
action to take (or warns him that they might get orphaned, or decides not to
remove the user even if the admin answered the debconf question saying "yes,
remove this").
Notice that policy, again, mandates that backups of conffiles should be purged
(http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails)
so packages should already have some kind of test to check to look for stale files in
configuration directories (that's not true for all, but those who don't are
buggy, so follow my point here). AS the precise naming of backup files is
open (from the manual: "~-files, #*# files, %-files, .dpkg-{old,new,tmp},
etc.") so the easiest way to test for the policy requirement is to check if
the configuration directory the package uses and see if it's empty after
removing all conffiles.
A standard test should cover both cases: backup files created by the admin
and new configuration files created by the admin there. Again, something that
could be reused by packages and integated into debhelp to prevent eveyrone
from writing his own piece of (sometimes buggy) code in maintainer scripts.
Of course, if the admin created the files outside of /etc/ (or /etc/$daemon)
then he would be on his own here [1]. That's why, again, the system user removal
should not be forced on all users, so knowledgeable users can say "no, don't
remove this user, I'm going to do stuff with it". But it should be a <=
medium debconf question.
Regards
Javier
[1] Running 'find /' is not an option since that could could be equivalent to
a DoS in some systems (those connected to SANs through network drives, for
example)
Attachment:
signature.asc
Description: Digital signature