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