don't require rootwrap config in etc

Bug #1408073 reported by Joe Gordon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oslo.rootwrap
Expired
Undecided
Unassigned

Bug Description

The current grenade model is we expect new code to work with old config. This means by default we test old rootwrap config with new code. This is a little strange since we don't expect users to configure rootwrap at all. Instead of requiring rootwrap config in /etc/ it would be nice to have some default values and store them in share or something.

This way users can overwrite the default rootwrap settings in /etc/ but we now can upgrade the default values in grenade.

Revision history for this message
Thierry Carrez (ttx) wrote :

So if I understand correctly, the issue you report is that the current setup (with a single config file) forces us to have rootwrap Kilo code work with Juno default config. If we separated default values in /usr/share from user customization in /etc, we could make backward-incompatible changes to the config and have them pass the Grenade test.

The problem is, how do you point rootwrap to that /usr/share location ? Currently the location of the unique config file in /etc is passed on the command line, and added in a sudoers entry. You can't hardcode the /usr/share location in code since every distro has a different idea of where that should be.

I guess we could encode some common location search, but that would be more brittle and weaken the simple security model (you just have one file location to secure right now).

Overall, since we don't plan to do backward-incompatible changes to the rootwrap config, the cost/benefit tradeoff just doesn't seem to be worth it...

Did I miss something ?

Changed in oslo.rootwrap:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for oslo.rootwrap because there has been no activity for 60 days.]

Changed in oslo.rootwrap:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.