Control: unmerge -1
Control: severity -1 wishlist
Control: retitle -1 dpkg-query: -S does not work with reverse symlinks from
/usr-merge
On Wed, 2017-03-22 at 16:38:50 +1100, Russell Coker wrote:
> On Wednesday, 22 March 2017 4:41:32 AM AEDT Guillem Jover wrote:
> > Not really, this case is the reverse, which is searching for the
> > canonical path on the filesystem, but which is not the canonical
> > one on the dpkg db.
> >
> > Solving this from the dpkg side, is non-trivial if not impractical.
> > It would require either scanning the whole filesystem to find aliased
> > pathnames. Or hardcoding the mappings, which would be encoding local
> > policy into dpkg somehow, which it might get out-of-sync with the
> > filesystem contents. Or possibly other ugly things.
>
> /etc/selinux/default/contexts/files/file_contexts.subs_dist has the following
> contents in the next policy for Unstable:
> /bin /usr/bin
> /lib /usr/lib
> /lib32 /usr/lib
> /lib64 /usr/lib
> /libx32 /usr/lib
> /sbin /usr/sbin
> /etc/init.d /etc/rc.d/init.d
> /lib/systemd /usr/lib/systemd
> /run/lock /var/lock
> /usr/lib32 /usr/lib
> /usr/lib64 /usr/lib
> /usr/libx32 /usr/lib
> /usr/local/lib32 /usr/lib
> /usr/local/lib64 /usr/lib
> /usr/local/lib /usr/lib
>
> Why not have a directory for config files listing equivalent paths for the
> purpose of dpkg -S etc? Above is the equivalency file for SE Linux, this is
> needed because SE Linux uses the canonical path name for the initial
> labelling
> of security contexts. To do that we need to know all the path names. Now
> the
> above isn't going to suit dpkg -S exactly. With SE Linux labelling we
> consider lib, lib32, lib64, and libx32 to be equivalent as the same file name
> in multiple directories has the same security implications but obviously not
> the same dpkg use.
>
> If we had a directory for subs files for the purpose of dpkg then usrmerge
> and
> anything else with similar operations could install a file to make dpkg -S
> work.
Hmmm, ok I guess, a "solution" could be:
* Add a new option "--map-pathname a b" or similar.
* When parsing the command-line or the config file fragments, check
whether the mapping corresponds to an existing reverse symlink,
and if not either warn or error out, so that these never get out
of sync.
* For each file in the db, match normally first, and otherwise try
each mapped pathname; if a mapped pathname matches probably warn
the user, and print the original pathname from the db (not the
mapped one).
This could go into /etc/dpkg/dpkg.cfg.d/usrmerge or whaterver, and more
importantly it should not affect users that do not use any such hack.
It still feels somehow wrong, and most probably it should not be enabled
by default, because if this is done transparently these paths might end
up on packages and similar, which would break on systems not /usr-merged.
And if it is not enabled by default, people will still complain that it
does not work out of the box anyway, so, as stated before it's still
impractical.
> > I covered this in #848622. So, unfortunately, this part, I don't think
> > is fixable. And as I've stated before, while I think the idea behind
> > merged-/usr is fine, the way it's been deployed is not, but this was
> > ignored as a non-issue, so…
> >
> > I think this should be wontfixed, and closed. But if someone can come
> > up with a clean way to handle this, I'm open to suggestions.
>
> It should not be closed. Set it to wontfix for the moment if you must, but
> please leave it open so it's a known issue (otherwise it will keep getting
> reported) and so that anyone else who has any ideas can add them.
Well the usrmerge bug could always be marked as affecting dpkg, but ok,
unmerged and massaged the metadata.
Thanks,
Guillem
