• Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category tools → pkgutils
  • Assigned To No-one
  • Operating System CRUX
  • Severity Low
  • Priority Very Low
  • Reported Version Development
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: CRUX
Opened by mark - 29.04.2006

FS#63 - Directory permissions are ignored

If a package contains a directory with permissions different from an existing directory, the permissions are changed when the package is installed. But when the package is removed, the new permissions persist.

Obviously keeping track of directory permissions would require massive changes and complicate the code. So in order to keep it simple, I think the right approach is to detect such differences as conflicts at install time, since it will permanently affect the system and it\'s likely that the change isn\'t on purpose.

mark commented on 29.04.2006 18:24

I\'d appreciate if someone would bump up the severity on this issue - it\'s the only serious flaw in pkgutils that I know of.

sten commented on 10.07.2006 12:52

This sounds a lot like the symptoms of a bad port. Changes to directory permissions should be noted in a README, or place in a post-install script, yes? IMHO, the detection should occur before the port is published (I have a kludgy routine for this as part of my htup script). Do you know of any ports in opt that change the permissions of directories installed by core? (core seems like it should be pretty much sovereign, as far as directory permissions go). If the problem is that packages clobber your personally-defined permissions, then perhaps you might be interested in cfengine. I haven\'t looked into cfengine much at all, but I understand that it is a really cool tool for maintaining a consistent system. (for example, you could have it run once a day to check and restore any directory permissions you would otherwise have to manually change, have it edit misc files, have it create misc files, etc.) Cfengine is another one of those projects that I thought might be neat to port to CRUX, but just haven\'t had the time to work on, and the way things are looking, probably never will...

jw commented on 12.07.2006 07:17

As noted in the related ML thread, there are a number of issues introduced by making permission changes a conflict, mainly two groups:

- a port changing one of its binaries to be suid root (or not suid root
anymore), or any other mode change

- a port (e.g. a daemon) changing to be run as nobody from root, thus
requiring its data file to be owned by nobody:nobody

- same problem: a port starting to use a particular group (think: video,
audio etc.) which previously used \'root\'

- human errors where a directory wasn\'t writable or a file not
executable, and fixed by the maintainer by changing a mode/ownership
of some files or directories

That\'s not to say that the feature shouldn\'t be added at all, but maybe we can find a different approach which doesn\'t have these annoyances

mark commented on 31.08.2006 12:53

I was sort of thinking about permission changes for directories, e.g. /usr/bin, since that\'s the only type of \"package object\" that is currently shared between packages. Obviously the package should be allowed to change the permissions of its *own* files as much as it wishes to.

An example of one port that used to change directory permissions, there was vsftpd which would chown /var/ftp to root:root since the \'filesystem\' package had the same directory owned by ftp:ftp (IIRC)

mark commented on 31.08.2006 13:01

Note that this change was intentional since vsftpd refuses to start with a ftp root which is writable by itself (\'ftp\'), but since it does change the system even after the package is removed, I think sysadmin intervention is reasonable.

jw: "a different approach which doesn't have these annoyances" might be to detect the conflicting permissions outside of pkgutils, and let the user decide what to do with the information. This is the approach taken by oldfiles, with respect to unneeded clutter in centralized directories. Taking oldfiles as inspiration, I wrote a new subroutine for prtcheckmissing that alerts users to unexpected permissions. Call the attached script from a symlink ending in "perms", and it will iterate through the installed ports, comparing footprints against what is found on the filesystem. Mismatches are sorted by file, and the offending ports are displayed alongside them. If the circumstance described in the original bug report are replicated, the directory with changed permissions will be flagged, and the user can decide whether to rebuild the port that still claims ownership of the directory. This handoff of responsibility to the user is simpler than trying to program an automatic rejection response into pkgutils, as there are legitimate reasons for a port to change a directory's owner or permissions.


Available keyboard shortcuts


Task Details

Task Editing