Bug 734582

Summary: Means to avoid wrecking /usr/local permissions on upgrade
Product: [Fedora] Fedora Reporter: Matt McCutchen <matt>
Component: filesystemAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-31 07:28:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt McCutchen 2011-08-30 19:44:54 UTC
Description of problem:
On my system, /usr/local is writable by wheel.  But the permissions get wrecked every time the "filesystem" package is upgraded.  There should be some way to avoid this.  The solution I am using is to split /usr/local (and /var/local for good measure) into a subpackage.  Alternately, RPM could gain support for %config(missingok,noreplace) for file attributes and the filesystem package could use it.

Version-Release number of selected component (if applicable):
filesystem-2.4.41-1.fc15

How reproducible:
Always

Steps to Reproduce:
As root:
1. chgrp -R wheel /usr/local
2. chmod -R g=u /usr/local
3. find /usr/local -type d -execdir chmod g+s {} +
4. yum reinstall filesystem
  
Actual results:
Permissions and ownership of dirs owned by the filesystem package are reset.

Expected results:
Permissions and ownership are not reset, or an alternate configuration is available in which they are not reset.

Comment 1 Ondrej Vasik 2011-08-31 07:28:41 UTC
Thanks for suggestion, but there is not much to do in that case in filesystem rpm. To prevent these issues in released Fedoras, I do not update filesystem package there... doing changes only in Rawhide... F15 was a bit special, because there was a VERY late request for changes required for systemd.

As for your suggestions -
%config() macro in spec file is only for files - not for directories - and it's behaviour for directories is at the best undefined. I don't like the idea of subpackage - because it will be necessary to require it by "primary" filesystem package - so there will be not a big benefit from it (unless you plan to exclude it from updates). In addition, doing such split would mean similar requests for other filesystem directories...

So - as a workaround - I suggest you to use rpm -U --excludepath=<path> - if done as an alias, it is easy to use and will work for other packages as well... other way is to propose a request for enhancement in rpm upstream tracker (http://rpm.org/newticket ).

Closing that one NOTABUG... sorry ... if you want to reopen it, please do so as RFE against rpm.

Comment 2 Matt McCutchen 2011-08-31 17:38:21 UTC
(In reply to comment #1)
> %config() macro in spec file is only for files - not for directories - and it's
> behaviour for directories is at the best undefined.

Extending the semantics of %config to file attributes (and allowing its use on directories) seems like an appropriate solution.  I will file a RFE with rpm upstream.  I would not be at all surprised if they decline, but maybe they will suggest an alternative.

> I don't like the idea of
> subpackage - because it will be necessary to require it by "primary" filesystem
> package - so there will be not a big benefit from it (unless you plan to
> exclude it from updates).

You're right.  What would be needed is to move the distro-managed content into a subpackage as well and convert "filesystem" to a metapackage.

> In addition, doing such split would mean similar
> requests for other filesystem directories...

I'm curious what other directories you anticipate people requesting?  The long-standing convention is that all the standard-ish dirs except those named "local" are managed by the distribution.

> So - as a workaround - I suggest you to use rpm -U --excludepath=<path>

For this to be a solution, yum would need to use it.  But this option is not even exposed in rpm-python.  I would have some patching to do.

Comment 3 Ondrej Vasik 2011-08-31 18:33:56 UTC
Yep, it sounds to be good idea to expose the --excludepath option to yum/rpm-python - it is useful for such cases. It will be great if you pursue that...

As for other directories I anticipate people could request split - I had similar requests for /usr (and some of its subdirs), /home and maybe some others - as some users use them as NFS mounts - see https://bugzilla.redhat.com/show_bug.cgi?id=526368 , https://bugzilla.redhat.com/show_bug.cgi?id=696329 , https://bugzilla.redhat.com/show_bug.cgi?id=538674 and https://bugzilla.redhat.com/show_bug.cgi?id=731964 ... people use various configurations and there is no "correct" one.