Bug#299007: Group staff in /usr/local: Moving forward
Hi Santiago,
I'm really sorry about the delay in responding to this. I'm going to copy
Joey on this message, since I suspect nearly all of the effective work in
the archive can be done by dh_usrlocal.
Joey, for background, this is about finally implementing the tech-ctte
decision that we should not make /usr/local group-writeable by staff going
forward. The decision was made some time ago, but we've been missing a
transition plan. We would be targetting jessie for this work
(paritcularly given that I put off replying to this message for about four
months).
Santiago Vila <sanvila@unex.es> writes:
> If the only thing we need here is a transition plan, here we go:
> I propose the following plan to change the *default* behaviour of group
> staff and /usr/local at the same time we completely keep backwards
> compatibility with already installed systems.
> First we modify base-files to do this:
> * On upgrades:
> from version < SOMEVERSION, create /etc/SOMEFILE.
> from version >= SOMEVERSION, do nothing.
> * On new installs, create /etc/SOMEFILE.
> Then we amend policy so that it reads like this:
> * Packages creating directories or putting files in /usr/local should:
> - Depend on base-files >= SOMEVERSION
> - Check if /etc/SOMEFILE exists.
> - If it exists, do things as current policy says.
> - If it does not exist, create directories 755 and root:root.
> After we change policy, we could start filing bugs, but they do not need
> to be RC yet.
I think the first step would be to change debhelper, ideally sometime near
the beginning of the development cycle for jessie. Then, regular uploads
would take care of most of the support.
> Instead, we wait for wheezy to be released.
> After the release of wheezy, we modify base-files in this way:
> * On upgrades, same as before:
> from version < SOMEVERSION, create /etc/SOMEFILE.
> from version >= SOMEVERSION, do nothing.
> * On new installs, do nothing (i.e. stop creating the file).
> And this is when we consider the bugs to be RC for wheezy+1, but we
> would have plenty of time to fix them (all the development stage for
> wheezy+1).
Yes, that sounds great.
> SOMEFILE would be something like /etc/staff-group-for-usr-local and it
> could even be self-documenting ("This file exist so that bla bla. if you
> remove this file after upgrading to wheezy+1, directories under
> /usr/local will be created root:root and 755").
I see that you've now implemented this in base-files, so the first step of
the plan is already underway. (And I'm glad that you didn't wait for a
reply on this.)
> I believe this plan makes the transition as smooth as possible. Please
> tell me if you see any flaw in it.
> I'll be happy to prepare a patch against policy with the required wording
> (and of course, do the required changes in base-files).
Yes, please, that would be great (barring any objections or concerns from
Joey or anyone else, but having a patch usually aids the discussion
anyway). We can then get this into Policy shortly after release and get
the change in front of everyone as they restart development.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: