On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote: > There should never be home or user based policies so they should go to a > system location. It doesn't matter to me, so long as the package manager > doesn't try mucking around in the module store directly. Why not home/user based policies? If the user can install software to $HOME (and they can), why not policy too? If the meta-policy stuff works out then you should be able to impose extra restrictions/add extra rules, but not reduce the security of the system surely? > uninstalling the policy RPM won't remove it from the policy. Since the > module installed to the system (/usr/share/selinux/policy or whatever) it > will be removed but the one in the module store (not owned by RPM) > wouldn't be. The RPM could probably use semodule to remove it as part of > the uninstallation phase though. The AP packages also need to be able to > handle this. OK. > However, say you are changing modules, you shouldn't uninstall one and > then install the other in seperate transactions because the applications > labels will become invalid (file and process). Of course the install of > the new module should try to relabel affected files, but you'd have > process labels invalidated in the process. The correct way is to start a > transaction, remove the old module, add the new one and commit. If the > type names change you'd have to shut down the application beforehand and > relabel the files afterward. Does semodule let you do this kind of atomic exchange? thanks -mike -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
