Re: on the use of chmod/chown in maintainer scripts
On Fri, 2012-05-18 at 13:49:19 +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote: That just leaves the question of wether dpkg uses uid/gid or symbolic names when unpacking debs. I think this one is clear: it must be symbolic since the uids/gids aren't static. Unless you want to provide a package-specific mapping in the control data, and I can't see that gains much, since it makes unpacking unnecessarily complex. If it's symbolic, you simply just extract it. Full ACK on symbolic. The question is what dpkg currently does. Do we need to fix dpkg or is dpkg already ready for this? Because deb packages use tar as the container, this restricts dpkg to what that supports. Non-ancient formats (i.e. non-V7 tar formats) store numeric and symbolic names for the file user and group. dpkg has always tried to use the symbolic name if it's been known to the system, and has used the numeric value as a fallback otherwise. Relying exclusively on numeric user/group would not be sane. So dpkg has always “been ready” for this. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120525010915.ga16...@gaara.hadrons.org
Re: on the use of chmod/chown in maintainer scripts
Roger Leigh rle...@codelibre.net writes: On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote: That just leaves the question of wether dpkg uses uid/gid or symbolic names when unpacking debs. I think this one is clear: it must be symbolic since the uids/gids aren't static. Unless you want to provide a package-specific mapping in the control data, and I can't see that gains much, since it makes unpacking unnecessarily complex. If it's symbolic, you simply just extract it. Full ACK on symbolic. The question is what dpkg currently does. Do we need to fix dpkg or is dpkg already ready for this? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umhlneo.fsf@frosties.localnet
Re: on the use of chmod/chown in maintainer scripts
Hi Peter, Thanks for bringing up this issue again. Admittedly, there hasn't been much progress since it was discussed last year. Hopefully, the discussion has focused on a solution to completely avoid the problem during upgrades. For the general issue, the only progress I made was in the form of #608623, but I haven't spent any time trying to implement lchmod in the kernel. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jp6rda$8st$1...@dough.gmane.org
Re: on the use of chmod/chown in maintainer scripts
Russ Allbery r...@debian.org writes: Charles Plessy ple...@debian.org writes: in some of my packages, I give the ownership on some directories in /var to www-data without checking that the www-data group exists, but I guess it is acceptable because it is globally allocated by base-passwd. Right. Dpkg will not update permissions or ownership, but when creating the directory it will apply the ones in the 'data' tar archive. So if there was no package released with wrong settings, I assume this is safe. Or am I simply relying on something undocumented and unwaranteed ? No, this is fine. But it only works for globally-allocated IDs in base-passwd. If you instead need to dynamically generate a system user on the fly and then set ownership of files to that user, which is a reasonably common case, this is more complex. Actualy not quite. This fails during bootstrap if base-passwd is not yet configured. While base-passwd is essential the /etc/passwd is only created during postinst and thus not covered by base-passwd being essential. So if you are essential (or pseudo essential, something essential depends on you) you have to depend on base-passwd to ensure your postinst is run after base-passwd is configured. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vgsqpc6.fsf@frosties.localnet
Re: on the use of chmod/chown in maintainer scripts
Roger Leigh rle...@codelibre.net writes: 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? Shouldn't be to hard to make fakeroot also create fake users and groups specified in debian/passwd and debian/group (or similar). That just leaves the question of wether dpkg uses uid/gid or symbolic names when unpacking debs. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nrgqp1l.fsf@frosties.localnet
Re: on the use of chmod/chown in maintainer scripts
On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: 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? Shouldn't be to hard to make fakeroot also create fake users and groups specified in debian/passwd and debian/group (or similar). fakeroot is the wrong level to do this. Think about how you are dependent upon the NSS databases and you need a valid db for the chown/chmod commands to work. Coupled with the fact that fakeroot is not required for building, I don't think this is a good plan. A wrapper around or replacement for chown/chmod is a possibility; this could store the changes in a file, rather than change the on-disc perms, ready for dpkg-deb to use. That just leaves the question of wether dpkg uses uid/gid or symbolic names when unpacking debs. I think this one is clear: it must be symbolic since the uids/gids aren't static. Unless you want to provide a package-specific mapping in the control data, and I can't see that gains much, since it makes unpacking unnecessarily complex. If it's symbolic, you simply just extract it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516130809.gb22...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
Guillem Jover writes (Re: on the use of chmod/chown in maintainer scripts): On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote: I can't see an equivalent in GNU tar. But BSD tar is available in Debian. This would imply BSD tar needs to be promoted to the Essential set alongside GNU tar, at which point I might as well just use an internal tar implementation. ??? Are we talking about unpack ? Because dpkg's unpack code already has an internal tar implementation. This is necessary to get all the file write / rename / conffile / etc. functionality to work properly. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20402.18142.743726.664...@chiark.greenend.org.uk
Re: on the use of chmod/chown in maintainer scripts
On Tue, May 15, 2012 at 01:06:54PM +0100, Ian Jackson wrote: || Guillem Jover writes (Re: on the use of chmod/chown in maintainer scripts): || On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote: ||I can't see an equivalent in GNU tar. But BSD tar is available ||in Debian. || || This would imply BSD tar needs to be promoted to the Essential set || alongside GNU tar, at which point I might as well just use an || internal tar implementation. || || ??? Are we talking about unpack ? Because dpkg's unpack code already || has an internal tar implementation. This is necessary to get all the || file write / rename / conffile / etc. functionality to work properly. No, this is about packing. Doing packing with dpkg-deb invoking bsdtar would either make bsdtar essential, or require that dpkg-deb switch to use whatever tar is available. Privately, I've succeeded in bypassing dpkg-deb entirely for packing, using bsdtar for creating tar-archives as well as ar-archives (for the .deb format). And no more need for a staging directory or for root privileges to ensure proper ownership for files in the tar-archive. Ciao. Vincent. -- Vincent Zweije vinc...@zweije.nl | If you're flamed in a group you http://www.xs4all.nl/~zweije/ | don't read, does anybody get burnt? [Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r. signature.asc Description: Digital signature
Re: on the use of chmod/chown in maintainer scripts
]] Vincent Zweije No, this is about packing. Doing packing with dpkg-deb invoking bsdtar would either make bsdtar essential, or require that dpkg-deb switch to use whatever tar is available. Why would it require more than dpkg-dev depending on bsdtar? We have precedence for packages being ok with not depending on everything they need for all parts of their functionality. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txzhikh0@xoog.err.no
Re: on the use of chmod/chown in maintainer scripts
* Russ Allbery (r...@debian.org) [120512 23:06]:
Charles Plessy ple...@debian.org writes:
Unless we expect that two different binary packages that can be
co-installed will distribute the same directory under different
ownership or permissions for a good reason, why not simply let dpkg
apply ownership and permissions found in data.tar.{gz|bz2|xz},
Usually because the UID is dynamically assigned and the user is created in
the postinst, so there's no way for dpkg do do this at unpack.
You would need to apply permissions by name, not UID/GID, and you would
need to create all users in preinst prior to unpack, which would require
Pre-Depends on adduser with all the complexity that entails. I haven't
thought through that path to see if there are any other problems.
Wouldn't it be sensible to describe which user(s) a programm needs as
well not by adduser $user but in a more abstract syntax and let dpkg
handle all of that?
Andi
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120513090626.gu2...@mails.so.argh.org
Re: on the use of chmod/chown in maintainer scripts
* Andreas Barth [2012-05-13 11:06 +0200]:
* Russ Allbery (r...@debian.org) [120512 23:06]:
Charles Plessy ple...@debian.org writes:
Unless we expect that two different binary packages that can be
co-installed will distribute the same directory under different
ownership or permissions for a good reason, why not simply let dpkg
apply ownership and permissions found in data.tar.{gz|bz2|xz},
Usually because the UID is dynamically assigned and the user is created in
the postinst, so there's no way for dpkg do do this at unpack.
You would need to apply permissions by name, not UID/GID, and you would
need to create all users in preinst prior to unpack, which would require
Pre-Depends on adduser with all the complexity that entails. I haven't
thought through that path to see if there are any other problems.
Wouldn't it be sensible to describe which user(s) a programm needs as
well not by adduser $user but in a more abstract syntax
I agree.
and let dpkg handle all of that?
This doesn't look like a task that should be done by dpkg itself;
instead debhelper or dpkg-maintscript-helper could be used.
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120513101924.ga19...@furrball.stateful.de
Re: on the use of chmod/chown in maintainer scripts
Hi, On 12/05/12 12:23, Peter Palfrader wrote: This may not be entirely trivial to solve. find | xargs constructs at best mitigate this to a race. While chown does have a --no-derefence flag, this does not protect us in the case of hardlinks. chmod has no such flag, and it'd useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one flag. From find(1): -links n File has n links. So I guess this specific problem could theoretically be solved this way. However, I'm actually also for a more general solution, as being discussed for dpkg or at least debhelper. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/joogrv$go4$1...@dough.gmane.org
Re: on the use of chmod/chown in maintainer scripts
Hi, Is there anybody familar with Solaris IPS manifests [1]? They are terrible and unflexible, but allow describing users, permissions etc. I thinks post/pre/install/remove scripts are create advantage, cause they allow do dirty things *iff* needed. [1] http://www.oracle.com/technetwork/server-storage/solaris11/technologies/ips-323421.html
Re: on the use of chmod/chown in maintainer scripts
On Sun, 13 May 2012, Leo costela Antunes wrote: Hi, On 12/05/12 12:23, Peter Palfrader wrote: This may not be entirely trivial to solve. find | xargs constructs at best mitigate this to a race. While chown does have a --no-derefence flag, this does not protect us in the case of hardlinks. chmod has no such flag, and it'd useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one flag. From find(1): -links n File has n links. So I guess this specific problem could theoretically be solved this way. However, I'm actually also for a more general solution, as being discussed for dpkg or at least debhelper. This creates just a race condition. Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513154944.gc19...@smithers.snow-crash.org
Re: on the use of chmod/chown in maintainer scripts
Carsten Hey cars...@debian.org writes: * Andreas Barth [2012-05-13 11:06 +0200]: * Russ Allbery (r...@debian.org) [120512 23:06]: Usually because the UID is dynamically assigned and the user is created in the postinst, so there's no way for dpkg do do this at unpack. You would need to apply permissions by name, not UID/GID, and you would need to create all users in preinst prior to unpack, which would require Pre-Depends on adduser with all the complexity that entails. I haven't thought through that path to see if there are any other problems. Wouldn't it be sensible to describe which user(s) a programm needs as well not by adduser $user but in a more abstract syntax I agree. You certainly don't have to convince me of that. :) *The* biggest thing that I wish I had time to do for Debian and don't is to write a high-level declarative language that would implement 80% of the current tasks of maintainer scripts and allow shell fragments duplicated in N packages (admittedly often generated by debhelper and therefore consistent and of high quality, but still requiring a rebuild to change in the rare case of a bug or requirements change in the debhelper behavior) with a declarative statement processed by one tool that can patched and updated as needed. There's a lot less than there used to be thanks to triggers, but still I bet 80-90% of the maintainer scripts in Debian could be eliminated in favor of a much simpler, pluggable system. and let dpkg handle all of that? This doesn't look like a task that should be done by dpkg itself; instead debhelper or dpkg-maintscript-helper could be used. Agreed. Putting it directly in the dpkg C code doesn't seem like a good separation of tasks, although it needs to be closely coordinated so that we can use the dpkg unpack stage to set ownership. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87havkowfl@windlord.stanford.edu
Re: on the use of chmod/chown in maintainer scripts
* Russ Allbery (r...@debian.org) [120513 18:52]: Carsten Hey cars...@debian.org writes: * Andreas Barth [2012-05-13 11:06 +0200]: and let dpkg handle all of that? This doesn't look like a task that should be done by dpkg itself; instead debhelper or dpkg-maintscript-helper could be used. Agreed. Putting it directly in the dpkg C code doesn't seem like a good separation of tasks, although it needs to be closely coordinated so that we can use the dpkg unpack stage to set ownership. dpkg doesn't mean dpkg C code, but part of the dpkg ecosystem (putting it in debhelper is better than nothing but as you pointed out not the real thing either). Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513173658.gv2...@mails.so.argh.org
Re: on the use of chmod/chown in maintainer scripts
Le Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader a écrit :
In some cases[1], this chmodding and chowning is done on each package upgrade,
either because things changed over time and just doing it unconditionally
seems
like the easiest thing, or just because hey, it doesn't hurt, does it?
Unfortunately, this can be a problem. Consider a tree /var/lib/example/ that
is owned or writeable by exuid. If, on upgrades, the package runs chown or
chmod -R /var/lib/example/, or does a chown or chmod on a specific node in
that
tree, this implies the possibility of privilige escalation.
Hi all,
I was always wondering:
Unless we expect that two different binary packages that can be co-installed
will distribute the same directory under different ownership or permissions for
a good reason, why not simply let dpkg apply ownership and permissions found in
data.tar.{gz|bz2|xz}, and treat it the same as a file conflict when unpacking a
package on a system where another package has already set different ownersip
and permissions ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512111010.gc31...@falafel.plessy.net
Re: on the use of chmod/chown in maintainer scripts
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.
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?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512112827.gq23...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
On 2012-05-12 13:10 +0200, Charles Plessy wrote:
I was always wondering:
Unless we expect that two different binary packages that can be co-installed
will distribute the same directory under different ownership or permissions
for
a good reason, why not simply let dpkg apply ownership and permissions found
in
data.tar.{gz|bz2|xz}, and treat it the same as a file conflict when unpacking
a
package on a system where another package has already set different ownersip
and permissions ?
An obvious obstacle is that dpkg does not currently track ownership and
permissions of installed files and directories in its database.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk9dpqr1@turtle.gmx.de
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512135523.ga...@gaara.hadrons.org
Re: on the use of chmod/chown in maintainer scripts
Charles Plessy ple...@debian.org writes:
Unless we expect that two different binary packages that can be
co-installed will distribute the same directory under different
ownership or permissions for a good reason, why not simply let dpkg
apply ownership and permissions found in data.tar.{gz|bz2|xz},
Usually because the UID is dynamically assigned and the user is created in
the postinst, so there's no way for dpkg do do this at unpack.
You would need to apply permissions by name, not UID/GID, and you would
need to create all users in preinst prior to unpack, which would require
Pre-Depends on adduser with all the complexity that entails. I haven't
thought through that path to see if there are any other problems.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vgxrtx3@windlord.stanford.edu
Re: on the use of chmod/chown in maintainer scripts
On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote: 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: 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. I found that this functionality is already present in BSD tar, according to the manpage. You can provide a file containing all the files to pack, plus their ownership and perms etc., rather than just specifying the files on the command-line. bsdtar(1) An input file in mtree(5) format can be used to create an output archive with arbitrary ownership, permissions, or names that differ from existing data on disk: $ cat input.mtree #mtree usr/bin uid=0 gid=0 mode=0755 type=dir usr/bin/ls uid=0 gid=0 mode=0755 type=file content=myls $ tar -cvf output.tar @input.mtree - I can't see an equivalent in GNU tar. But BSD tar is available in Debian. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512214722.gl23...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote: On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote: 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. I found that this functionality is already present in BSD tar, according to the manpage. You can provide a file containing all the files to pack, plus their ownership and perms etc., rather than just specifying the files on the command-line. bsdtar(1) An input file in mtree(5) format can be used to create an output archive with arbitrary ownership, permissions, or names that differ from existing data on disk: [...] - Yeah, mtree is actually one of the things I've been having in mind when considering ways to store file metadata in the dpkg suite. I can't see an equivalent in GNU tar. But BSD tar is available in Debian. This would imply BSD tar needs to be promoted to the Essential set alongside GNU tar, at which point I might as well just use an internal tar implementation. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513001013.gb6...@gaara.hadrons.org
Re: on the use of chmod/chown in maintainer scripts
On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote: On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote: On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote: 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. I found that this functionality is already present in BSD tar, according to the manpage. You can provide a file containing all the files to pack, plus their ownership and perms etc., rather than just specifying the files on the command-line. bsdtar(1) An input file in mtree(5) format can be used to create an output archive with arbitrary ownership, permissions, or names that differ from existing data on disk: [...] - Yeah, mtree is actually one of the things I've been having in mind when considering ways to store file metadata in the dpkg suite. I can't see an equivalent in GNU tar. But BSD tar is available in Debian. This would imply BSD tar needs to be promoted to the Essential set alongside GNU tar, at which point I might as well just use an internal tar implementation. Won't this only be needed for /packing/ the archive though? Can't any tar implementation still be used for unpacking? Or would dpkg-deb be constrained to a single tar for both operations? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513001735.gp23...@codelibre.net
Re: on the use of chmod/chown in maintainer scripts
Le Sat, May 12, 2012 at 02:06:16PM -0700, Russ Allbery a écrit : Usually because the UID is dynamically assigned and the user is created in the postinst, so there's no way for dpkg do do this at unpack. You would need to apply permissions by name, not UID/GID, and you would need to create all users in preinst prior to unpack, which would require Pre-Depends on adduser with all the complexity that entails. I haven't thought through that path to see if there are any other problems. I see, [please do not hesitate to answer on -mentors if I am getting trivial] in some of my packages, I give the ownership on some directories in /var to www-data without checking that the www-data group exists, but I guess it is acceptable because it is globally allocated by base-passwd. The way I do is simply to set the ownership when building the package, and let dpkg do the rest for me. For instance in emboss-explorer: $ dpkg -c emboss-explorer_2.2.0-7_all.deb | grep -C 2 www-data drwxr-xr-x root/root 0 2008-12-07 23:41 ./var/lib/ drwxr-xr-x root/root 0 2008-12-07 23:41 ./var/lib/emboss-explorer/ drwxr-xr-x www-data/www-data 0 2008-12-07 23:41 ./var/lib/emboss-explorer/output/ drwxr-xr-x root/root 0 2008-12-07 23:41 ./usr/ drwxr-xr-x root/root 0 2008-12-07 23:41 ./usr/lib/ Dpkg will not update permissions or ownership, but when creating the directory it will apply the ones in the 'data' tar archive. So if there was no package released with wrong settings, I assume this is safe. Or am I simply relying on something undocumented and unwaranteed ? Have a nice Sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513003701.gd19...@falafel.plessy.net
Re: on the use of chmod/chown in maintainer scripts
On Sun, 2012-05-13 at 01:17:35 +0100, Roger Leigh wrote: On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote: This would imply BSD tar needs to be promoted to the Essential set alongside GNU tar, at which point I might as well just use an internal tar implementation. Won't this only be needed for /packing/ the archive though? Can't any tar implementation still be used for unpacking? Or would dpkg-deb be constrained to a single tar for both operations? Well strictly speaking, yes it would only be needed for «dpkg-deb -b». For dpkg --unpack, GNU tar is not even used, an internal implementation is used instead, so that proper control of what's going on can be done. But having dpkg-deb either use BSD tar only for extraction or for both building and extraction would require for it to depend on BSD tar being present, and I don't think we can get rid of GNU tar from Essential at this point in time anyway, that's where my comment was coming from. And making dpkg-deb use either GNU or BSD tar depending on which one is present does not seem too compelling. Also because some of the code has to be written anyway for the internal tar extractor, it should not be much work to add the building side. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513004805.ga9...@gaara.hadrons.org
Re: on the use of chmod/chown in maintainer scripts
Charles Plessy ple...@debian.org writes: in some of my packages, I give the ownership on some directories in /var to www-data without checking that the www-data group exists, but I guess it is acceptable because it is globally allocated by base-passwd. Right. Dpkg will not update permissions or ownership, but when creating the directory it will apply the ones in the 'data' tar archive. So if there was no package released with wrong settings, I assume this is safe. Or am I simply relying on something undocumented and unwaranteed ? No, this is fine. But it only works for globally-allocated IDs in base-passwd. If you instead need to dynamically generate a system user on the fly and then set ownership of files to that user, which is a reasonably common case, this is more complex. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa1crji4@windlord.stanford.edu
