Let's not compare init scripts with dpkg scripts. The issue at hand here is that dpkg, and dpkg scripts do not install files with the correct context.
As a Fedora user, i am not very familiar with dpkg, but i can tell you that rpm, and the rpm script mechanism are SELinux aware. They use the matchpathcon(), and setfscreatecon() libselinux functions to query what the security contexts of a to be installed object should be, and to install objects with the security contexts returned by matchpathcon() using setfscreatecon() or similar libselinux functions. For inspiration, i would suggest one studies the SELinux commits in the rpm repository. If dpkg cannot, because it uses a different mechanism for dpkg script than rpm does for rpm scripts, deal with those scripts in a similar way then a other solution should be thought of. For example create a hook that gets called in dpkg scripts if it is determined that SElinux is enabled on the target system that runs restoreon. The idea is that policy defines/maintains a list with file context specifications, restorecon and matchpathcon commands query hat list to determine what a specified location should be labeled. Restorecon additionally resets the context of a specified location according to what is specified system wide in the file context specifications. So its a one, or two step procedure: prefered (not racy) (see libselinux: http://selinuxproject.org/page/LibselinuxAPISummary ) matchpathcon() "object": determine what a specified "object" should be labeled by querying the system wide file context specifications define by security policy, and or admin setfscreatecon() "object" (see man setfscreatecon): create the specified object with the context that was returned by the matchpathcon() function. alternate (racy): use the restorecon/setfiles "object" commands to reset the context of a specified object to what is specified system wide in the file context specifications define by policy, and admin I would suggest one takes a good look at how rpm deals with this, and apply their solution where applicable, because rpm has been doing this for quite a while and so we can imagine that they have learned a lot and adjusted to the optimal way of going things. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
