Re: What is the correct way to set owner to package's files?
Hi!
On Wed, 2015-12-30 at 16:46:23 +0300, Konstantin Khomoutov wrote:
> Two caveats:
>
> 1) Be aware that a user "foo" on your build system might have different
> UID than the user "foo" on the customer's system, and files' metadata
> has owning user and group recorded as a pair of integers -- UID and
> GID, respectively.
The deb(5) format stores the file attributes as part of the tar archive,
which records both numeric ids and their string representation. The
string names are used if the system knows about those names, otherwise
dpkg will gracefully fallback to use the numeric ids.
> IOW, these integers are not portable across systems (unless user
> and group database is in LDAP or NIS or otherwise centralized and
> shared by these systems), and you have to make sure that when your
> package is unpacked to the target filesystem, the UIDs and GIDs on
> its files belong to the user they should.
Actually, you'd just need to make sure the user and group names exist
before the package gets extracted. You can do that in the preinst.
> 2) Newer Debian packaging often uses a generic helper sequencer, `dh`,
> wich is able to reduce debian/rules to a mere couple of lines.
> If this does not work (with the point (1) above being especially
> problematic, IMO), you might have better luck with post-installation
> fixup of the permissions. The idea is that the list of files a package
> contains is located in /var/lib/dpkg/info/{packagename}.list file,
> so in your postinst script (maybe even in preinst -- after the package
> is unpacked -- I can't remember the exact details, please refer to the
> Debian policy which explains all these things) you should be able to
> read this file and feed it to something fixing up permissions, like
>
> xargs -n 30 chmod foo:foo \
> < /var/lib/dpkg/info/{packagename}.list
The dpkg database is supposed to be private and an internal
implementation detail. There's a perfectly usable public interface for
this: «dpkg-query -L», please use that instead.
But in any case I think this is a bad idea, as it will stomp over
dpkg-statoverride(1)s.
> provided your script first called `useradd` to add that user and/or may
> be first verified it already exists via calls to `getent passwd foo`
> and `getent group foo` etc.
Depending on the usage you might want to use adduser instead. But then,
if you use it in preinst you'll need a Pre-Depends.
Thanks,
Guillem
Reply to: