On Tue, 07 Oct 2014, Paul Gevers wrote: > I am trying to come up with a patch against dpkg-statoverride that sets > the ownership and permissions upon creation, but not upon updates.
This really doesn't look like a good idea. In fact, it may well introduce very confusing and likely dangerous behavior. Anyway, are you sure dpkg-statoverride is the correct tool for your usecase in the first place? If you want to set ownership and permisions upon creation but not on updates, this is should not be a job for the statoverride database. The debconf database or an ucf-managed config file under /etc somewhere seems much better suited to store information only to be used at creation time, at least in the general case. The dpkg-statoverride database is in the _job_ of *clobbering* permission and ownership information of filesystem objects, and it is very security sensitive. It is not there only to handle local customization, either: it is an essential component of the internals of the debian packaging system when dealing with security-sensitive filesystem objects that need to be created or replaced while a package is unpacked. You often need to interact with the statoverride database in preinst, so that files will be created/replaced atomically by dpkg with the already correct ownership and permission information. This logic applies to anything that uses it. When something is registered through dpkg-statoverride, it must be managed through dpkg-statoverride. Directly changing those permissions in the filesystem is *unsupported* in the sense that they are _expected_ to be clobbered the next time that file is modified by the packaging system (and that includes maintainer scripts). I really don't think it is wise to mess with this basic assumption. If it is invalid for your usecase, it most likely means you are using the wrong tool for the job. BTW: the statoverride databased has to be queried by dpkg for every filesystem object it has to create/replace while unpacking _any_ package. Anyway, if you're still going to use dpkg-statoverride anywhere the local admin might rightfully expect permission/ownership changes to stick, I suggest you seriously consider taking a heavy-handed approach to ensure the local admins *know* they have to go through dpkg-statoverride to change the permissions and ownership information of those filesystem objects. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007212301.gb3...@khazad-dum.debian.net
