Re: Bug#484841: staff group root equivalence

[Russ Allbery <rra@debian.org>]

Andreas Barth <aba@not.so.argh.org> writes:

> However, I'm not sure if that's the best way to achieve it - I didn't
> try out but I'd assume that any directory in a deb won't get the group
> inherited from the parent directory. I think that a Post-Invoke-action
> in apt.conf would be the better way. (We should probably document that
> somewhere how to achive it.)

Policy requires that you not ship directories in /usr/local in the deb.

    However, the package may create empty directories below /usr/local
    so that the system administrator knows where to place site-specific
    files. These are not directories in /usr/local, but are children of
    directories in /usr/local. These directories (/usr/local/*/dir/)
    should be removed on package removal if they are empty.

    Note, that this applies only to directories below /usr/local, not in
    /usr/local. Packages must not create sub-directories in the
    directory /usr/local itself, except those listed in FHS, section
    4.5. However, you may create directories below them as you wish. You
    must not remove any of the directories listed in 4.5, even if you
    created them.

    Since /usr/local can be mounted read-only from a remote server,
    these directories must be created and removed by the postinst and
    prerm maintainer scripts and not be included in the .deb
    archive. These scripts must not fail if either of these operations
    fail.

so I think requiring maintainer script changes is the best way to do
this.  I don't think using apt.conf options to clean up after maintainer
script changes will work well.

> Anyways, I think we should do the basic decision whether we want to
> /usr/local to be writeable by staff or not soon, and then try how to
> best do a transition.

I would prefer to drop the writeability of /usr/local by staff
personally.  I don't think it serves much useful purpose these days
given the existence of tools like sudo, and where it does, I think we
can work out a transition plan that will make it relatively easy for
sites to recreate the concept.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>