[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#203650: marked as done (Poor recommendation in dpkg-statoverride section)

Your message dated Fri, 06 Jun 2008 11:46:57 -0700
with message-id <[🔎] 87ej7atn8e.fsf@windlord.stanford.edu>
and subject line Rejected: Bug#203650: Poor recommendation in dpkg-statoverride section
has caused the Debian Bug report #203650,
regarding Poor recommendation in dpkg-statoverride section
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
203650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203650
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy

Here's the current text of the latter part of section 10.9.1:

============
Given the above, dpkg-statoverride is essentially a tool for system
administrators and would not normally be needed in the maintainer
scripts. There is one type of situation, though, where calls to
dpkg-statoverride would be needed in the maintainer scripts, and that
involves packages which use dynamically allocated user or group
ids. In such a situation, something like the following idiom can be
very helpful in the package's postinst, where sysuser is a dynamically
allocated id:

     for i in /usr/bin/foo /usr/sbin/bar
     do
       if ! dpkg-statoverride --list $i >/dev/null
       then
         dpkg-statoverride --update --add sysuser root 4755 $i
       fi
     done

The corresponding dpkg-statoverride --remove calls can then be made
unconditionally when the package is purged.
============

This means that the files are unpacked with whatever permissions were
in the package, and are then modified during postinst. In addition, if
the sysadmin removes the statoverride entry, the postinst will blindly
add it back again later.

So, let's break down what happens a bit:

 - dpkg unpacks the files, with their original permissions
 - postinst creates a user
 - postinst adds a statoverride to change the permissions

The "problem" is that the user doesn't exist until after you unpack
the files. Adding a statoverride here is a somewhat strange approach
in its own right, ignoring such matters as the period between unpack
and configure when permissions/owners are wrong.

I suggest that this sequence would make more sense:

 - preinst creates a user
 - dpkg unpacks the files

It's easier to understand and doesn't tread on the admin's toes as
much. Note that dpkg stores users by name, not by uid.

I propose replacing the above text entirely with this:

============
Given the above, dpkg-statoverride is a tool for system
administrators and is not needed in the maintainer scripts.
============

And appending this text to section 10.9:

============
If you want files in a package to be owned by a dynamically allocated
user or group, then you should create the user or group in preinst, so
that it is present when the package is unpacked.
============

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: pgpvqHoIJ5dea.pgp
Description: PGP signature


--- End Message ---
--- Begin Message --- 
This proposal concerns packages that need to have files owned by a
dynamically created user.  Currently, Policy recommends use of
dpkg-statoverride in postinst to change the ownership to the dynamically
created user after the user has been created.  This Policy proposal would
instead create the user in preinst and ship the package with files already
owned by the dynamic user (by name) in the *.deb file so that when it was
unpacked, the files would already be correctly owned.

In the discussion of this proposal, multiple problems were identified,
ranging from needing to Pre-Depend on adduser to the difficulty of
creating Debian packages with files owned by a dynamically created user.
So far as I can tell from the bug log, none of those problems have been
addressed and making this change would still be quite challenging from a
technical perspective.

Given that the Policy change is premature until the technical difficulties
with implementing this change have been ironed out, I'm rejecting this
proposal at this time.  Anyone is welcome to re-propose this change once
the technical problems have been resolved (assuming that there is
consensus to do the technical work that this change would require).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

--- End Message ---
Reply to: