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

Re: on the use of chmod/chown in maintainer scripts



On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote:
> On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> > A lot of daemon packages in Debian nowadays create their own user and groups
> > during installation.  Usually this also implies that a couple of files and
> > directories are created, and then chmodded and chowned to some appropriate
> > value for the service in question.
> > 
> > Any ideas what we should do?
> 
> Like for other parts of the packaging and maintainer scripts, I think
> this is something which should be entirely declarative, and handled
> at the dpkg or debhelper level.
> 
> In the case of adding users and groups, it would be helpful to have
> e.g. a dh_user and/or dh_group script which look at
> debian/${package}.(user|group) and put the appropriate
> adduser/useradd commands into the package preinst or postinst, and
> depends/pre-depends on the needed tools as appropriate.
> This can also add the appropriate commands for removal in the postrm
> (or not, as the consensus currently appears to be).  But the policy
> for that can be set by debhelper.
> 
> Why the preinst?  If all static or dynamic users and groups are made
> available before unpacking the data.tar, we can just unpack the tar
> and the users/groups in the files and directories could be
> automatically used.  No manual chmod/chown would be required, since
> this would all be handled transparently by dpkg.

Right, this came up some time ago when Lars blogged about it, my reply
to that can be found there:

  <http://blog.liw.fi/posts/addsysuser/>

> With the above approach, the only hard question is how to set the
> ownership during the package build.  fakeroot handles this just fine,
> but it does require the user/group to be present on the build
> system, which will not always be the case.  Is there an alternative
> means to set/override the ownership during packing of a tarfile?

One option would be to make dpkg-deb use an internal tar implementation,
and add a file describing the attributes of the to be packaged files.
That might make needing root privs (either through fakeroot or sudo)
unneeded in most of the cases too.

regards,
guillem


Reply to: