CRUX

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.

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...

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

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)

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.