Re: dpkg-statoverride vs. suidmanager
Argh, I think I missed a problem with this idea. So the idea is:
* New Dpkg conflicts with old suidmanager.
* New suidmanager depends on new dpkg, and on upgrade, imports all
local suid.conf overrides into statoverride.
* New packages do not need to register with suidregister, so they will
contain actual suid executables.
The problem is, what happens when a user installs a new package on an
old system? Let's say they had overridden the permissions of a file in
the package using suidmanager. It doesn't use suidmanager anymore, and
they don't have the new dpkg/suidmanager, so their wishes are ignored
and they get a suid executable.
I don't think that's acceptable. I'm back to thinking every package that
used to use suidregister and now uses statoverride needs a versioned
dependany on dpkg, or a versioned conflicts with old versions of
suidmanager.
--
see shy jo
Reply to: