Bug#720517: configuration files, ownership and dpkg-statoverride
On 09-10-14 02:17, Henrique de Moraes Holschuh wrote: On Wed, 08 Oct 2014, Paul Gevers wrote: Thanks for the careful response. And no, as mentioned above, I didn't mean to use dpkg-statoverride itself. dbconfig-common uses debconf and ufc to manage the configuration files. However, dbconfig-common checks with dpkg-statoverride if the configuration file is registered there and takes action if it is. However, currently it relies only on dpkg-statoverride to know if the ownership of the configuration file should be different, I want dbconfig-common to leave the ownership as it is if the file already exists. It looks like your problem is the situation where you have dpkg-statoverride information and it contradicts whatever is in debconf (or the filesystem, for that matter)? Actually, I was really thinking about the situation where dpkg-statoverride AND debconf were NOT used. dbconfig-common allows a package to specify the ownership and permissions of the configuration file. The package may or may not do this via debconf (cacti currently does not). If a local admin decides that the ownership and/or permissions need to be different dbconfig-common should honor that when updating the package. Until know (hence RC) dbconfig-common changed the ownership and permissions unconditionally to the ownership and permissions requested by the package (unless dpkg-statoverride was used by the admin), which may not be what the admin wants (and as you state below may not reflect the situation). In that case, it is an operator error: I suggest you inform him about it and refuse to continue. There's no other safe choice in the general case, AFAIK. But this indeed is a good idea. Lots more logic to add, but indeed. Annoying thing is that the script that actually does the file writing may be called manually as well. Let me ponder on this some time. Of course, it might happen that you have specific knowledge (such as you know the dpkg-statoverride information was added in error by a previous version of the package _and_ the information in the statoverride database exactly matches the one the bug would have caused) which allows you to automatically repair the problem, instead. Sure, but AFAICT that is not the case here. And if we're talking about an initial question (i.e. there is no conflict because there's nothing in the debconf database yet), then wouldn't using the dpkg-statoverride information as a pre-seed _and_ not allowing it to be overriden through debconf (i.e. don't ask the user about it at all) solve the issue? Not applicable for the bug at hand, because there never was a question to the user. Just hard-coding in the package, which I think is acceptable, as well as it should be acceptable that the package leaves it to dbconfig-common to just do-the-right-thing in this case. Paul signature.asc Description: OpenPGP digital signature
Bug#720517: configuration files, ownership and dpkg-statoverride
Paul Gevers writes (Re: Bug#720517: configuration files, ownership and dpkg-statoverride): On 07-10-14 15:40, Ian Jackson wrote: Also I don't see in your references an explanation from anyone as to why dbconfig-common does this. I you mean with why: why is it implemented this way than that is exactly the question that I am asking myself looking at the code, if you mean why does dbconfig-common change the ownership of cactis configuration file than the answer is that you can tell dbconfig-common in your maintainer scripts what the (I expected initial) ownership should be. Why does dbconfig-common have this feature ? Why does cactis use it ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720517: configuration files, ownership and dpkg-statoverride
On 08-10-14 13:58, Ian Jackson wrote: Paul Gevers writes (Re: Bug#720517: configuration files, ownership and dpkg-statoverride): On 07-10-14 15:40, Ian Jackson wrote: Also I don't see in your references an explanation from anyone as to why dbconfig-common does this. I you mean with why: why is it implemented this way than that is exactly the question that I am asking myself looking at the code, if you mean why does dbconfig-common change the ownership of cactis configuration file than the answer is that you can tell dbconfig-common in your maintainer scripts what the (I expected initial) ownership should be. Why does dbconfig-common have this feature ? Because some packages need the configuration file to be owned (or grouped) by the user under which a package is running. Why does cactis use it ? The cacti configuration file contains a password to the database, so it must be readable by the httpd, but not readable by all other users of the system. Therefore the ownership is root:www-data. Paul signature.asc Description: OpenPGP digital signature
Bug#720517: configuration files, ownership and dpkg-statoverride
Hi, I am looking into dbconfig-common RC bug 720517 [1] and I was wondering what the general idea is of maintainer scripts changing the permissions and/or owners of configuration files and the use of dpkg-statoverride. I myself find it unacceptable that updating a package changes the permissions/owners of a configuration file without asking, even when I have not documented that fact with dpkg-statoverride. At least that is how I read policy 10.7.3 [2]. Do other people find it sensible that you need to document this fact with dpkg-statoverride? In other words, is it ok to change permissions and ownership as done by dbconfig-common if you didn't? Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720517 [2] https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3 signature.asc Description: OpenPGP digital signature
Bug#720517: configuration files, ownership and dpkg-statoverride
Paul Gevers writes (configuration files, ownership and dpkg-statoverride): I am looking into dbconfig-common RC bug 720517 [1] and I was wondering what the general idea is of maintainer scripts changing the permissions and/or owners of configuration files and the use of dpkg-statoverride. The user should not be expected or required to use dpkg-statoverride on configuration files (whether they are dpkg-managed conffiles or maintainers-script-managed). chmod/chown should be sufficient. I myself find it unacceptable that updating a package changes the permissions/owners of a configuration file without asking, even when I have not documented that fact with dpkg-statoverride. At least that is how I read policy 10.7.3 [2]. I think you are right. But I don't see anyone disputing this. Also I don't see in your references an explanation from anyone as to why dbconfig-common does this. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720517: configuration files, ownership and dpkg-statoverride
On 07-10-14 15:40, Ian Jackson wrote: Also I don't see in your references an explanation from anyone as to why dbconfig-common does this. I you mean with why: why is it implemented this way than that is exactly the question that I am asking myself looking at the code, if you mean why does dbconfig-common change the ownership of cactis configuration file than the answer is that you can tell dbconfig-common in your maintainer scripts what the (I expected initial) ownership should be. dbconfig-common than sets the ownership on every update of the package where it is called, except when dpkg-statoverride is set. I am trying to come up with a patch against dpkg-statoverride that sets the ownership and permissions upon creation, but not upon updates. Paul signature.asc Description: OpenPGP digital signature
Bug#720517: configuration files, ownership and dpkg-statoverride
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-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
