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
Reply to: