Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
On Wed, 2012-10-10 at 05:44:25 +0200, Michael Biebl wrote: On 08.10.2012 22:53, Guillem Jover wrote: That applies as well to any path generated at maintainer script or run time by the package (like state, cache, log files, etc), but I don't think it's currently a good idea for these to belong in the dpkg database, as either the files' md5sums might change over time, or the paths might appear and disappear if they are on a ramfs, or Interesting question regarding generated files and md5sums. Maybe it would be best to simply not store md5sums for such externally registered files/directories. Ideally dpkg could be told what kind of file it was when registering it, say for example if it changes its contents during its lifetime (a log file), and/or if it's normal for it to simply vanish at any moment (a cache), so that it could know what to possibly expect. worse might cause security issues if they are world writable (like /var/lock, as Jakub has pointed out). Well, my idea was not, that dpkg should actually create that file/dir, but simply that it tracks the information that such a file/dir is created by the package. Where do you see the security risk wrt dpkg? If dpkg is just tracking them for listing and searching purposes, then sure. That was a reference to packages currently shipping those paths, as has been mentioned on this thread. But if dpkg is tracking them, I'd think it really makes sense for it to deal with them for example on remove or purge (although we might possibly want to make that configurable somehow, so that one could say for example that logs should be kept, which would get rid of that whole discussion about if those files should or should not be removed by each different package, and would unify the current behaviour). On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote: like ucf config files This will be covered instead by extending the dpkg conffile support to allow to register external configuration files. Interesting. Can you say a bit more about that, how this is going to work. If you register an external configuration file with dpkg, will dpkg take care of removing it on purge or does that still need to be done by the package itself? Yeah, I've not fleshed out the details yet, but in principle they would just behave like conffiles, but instead of the new contents coming from the .deb they would come from the stuff generated by the maintainer script. or even ressources like system users and groups. I'm not entirely sure what you mean with this though, maybe something like #685734? Not quite, although #685734 sounds like an interesting idea. I'm basically just interested in having a central database where packages can register which ressources they are using, so I can easily query it later on, e.g. which package created and/or uses a specific system user. Ok, could you then add a note of that to the bug report, it's not strictly speaking the same, but the bug can always be cloned or something. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121022185630.gb31...@gaara.hadrons.org
Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
Hi guillem! On 08.10.2012 22:53, Guillem Jover wrote: On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote: On 08.10.2012 20:15, Michael Gilbert wrote: I actually find it pretty handy if I can use dpkg -S to find out which package a particular directory belongs to. So shipping the directory in the package does have some value (at least for me). That applies as well to any path generated at maintainer script or run time by the package (like state, cache, log files, etc), but I don't think it's currently a good idea for these to belong in the dpkg database, as either the files' md5sums might change over time, or the paths might appear and disappear if they are on a ramfs, or Interesting question regarding generated files and md5sums. Maybe it would be best to simply not store md5sums for such externally registered files/directories. worse might cause security issues if they are world writable (like /var/lock, as Jakub has pointed out). Well, my idea was not, that dpkg should actually create that file/dir, but simply that it tracks the information that such a file/dir is created by the package. Where do you see the security risk wrt dpkg? aba rightfully pointed out, that having a mechanism in dpkg which allows one to register such a directory in the dpkg database dynamically, might be an even better approach. Such a mechanism could not only be used to register such volatile files/directories in (/var)/run or /lock but files that are generated by the maintainer scripts Sure, and that's been on the dpkg TODO list for a while, but it needs first for its database to be extended to track additional metadata. I was planning on working on this for 1.17.x anyway. like ucf config files This will be covered instead by extending the dpkg conffile support to allow to register external configuration files. Interesting. Can you say a bit more about that, how this is going to work. If you register an external configuration file with dpkg, will dpkg take care of removing it on purge or does that still need to be done by the package itself? or even ressources like system users and groups. I'm not entirely sure what you mean with this though, maybe something like #685734? Not quite, although #685734 sounds like an interesting idea. I'm basically just interested in having a central database where packages can register which ressources they are using, so I can easily query it later on, e.g. which package created and/or uses a specific system user. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
On 08.10.2012 20:15, Michael Gilbert wrote: On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: Packages must not include files or directories under /run, or under the older /var/run and /var/lock paths. The thing is that it really does no harm if a package actually does this; although it is pretty pointless since those files will be gone I actually find it pretty handy if I can use dpkg -S to find out which package a particular directory belongs to. So shipping the directory in the package does have some value (at least for me). aba rightfully pointed out, that having a mechanism in dpkg which allows one to register such a directory in the dpkg database dynamically, might be an even better approach. Such a mechanism could not only be used to register such volatile files/directories in (/var)/run or /lock but files that are generated by the maintainer scripts like ucf config files or even ressources like system users and groups. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
Hi! On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote: On 08.10.2012 20:15, Michael Gilbert wrote: On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: Packages must not include files or directories under /run, or under the older /var/run and /var/lock paths. The thing is that it really does no harm if a package actually does this; although it is pretty pointless since those files will be gone I actually find it pretty handy if I can use dpkg -S to find out which package a particular directory belongs to. So shipping the directory in the package does have some value (at least for me). That applies as well to any path generated at maintainer script or run time by the package (like state, cache, log files, etc), but I don't think it's currently a good idea for these to belong in the dpkg database, as either the files' md5sums might change over time, or the paths might appear and disappear if they are on a ramfs, or worse might cause security issues if they are world writable (like /var/lock, as Jakub has pointed out). aba rightfully pointed out, that having a mechanism in dpkg which allows one to register such a directory in the dpkg database dynamically, might be an even better approach. Such a mechanism could not only be used to register such volatile files/directories in (/var)/run or /lock but files that are generated by the maintainer scripts Sure, and that's been on the dpkg TODO list for a while, but it needs first for its database to be extended to track additional metadata. I was planning on working on this for 1.17.x anyway. like ucf config files This will be covered instead by extending the dpkg conffile support to allow to register external configuration files. or even ressources like system users and groups. I'm not entirely sure what you mean with this though, maybe something like #685734? thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121008205332.ga13...@gaara.hadrons.org
