Re: What is the correct way to set owner to package's files?
On Wed, 30 Dec 2015 16:19:18 +0300
Dmitrii Kashin <d.kashin@solarsecurity.ru> wrote:
> >> Our company is distributing some software splitted into packages
> >> (deb and rpm). Almost all files are installed into /opt/<prefix>
> >> and specifically all of them must be owned by some user <user>.
> >>
> >> My duty is to set up packaging of them all. And I have a problem:
> >> I'm using chroot environments to build out software, build process
> >> run under the root user and therefore all the files
> >> in /opt/<prefix> are owned by root. I need them to be owned by
> >> <user>.
> >
> > Do you *really* need this?
>
> I hesitate, but yes. I do need specifically this.
[...]
> I understand the importance of the problem you described, and that it
> should be solved, and I'll try to find time to fix it to. But there's
> a big proglem to categorize all the files in project, because it's
> more than 32 thousands of them.
OK, it's good you have understanding of the repercussions and are
willing to eventually push for a proper fix.
So, back to your problem.
If you're using Debian's native tools to build your packages,
that is, `dpkg-buildpackage` (maybe through any number of layers on top
of it -- such as `debuild` or `git-buildpackage` etc), then look at
the invocation of the `dh_fixperms` helper script which usually gets
executed by debian/rules of your package. This helper is responsible
for bringing the permissions of the package's files into a sane state
(see `man dh_fixperms`).
So, the first route to explore is to comment out all calls to this
helper in debian/rules and see if this will be enough to have the
package's files be owner by your specific user.
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.
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.
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 your packaging relies on it rather than on older explicit calling
of the helper, you'll need to create a special no-op target in your
debian/rules file: "override_dh_fixperms" to forfeit the call to
`dh_fixperms`. Refer to `man dh` for more info.
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
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.
[...]
> Well it's a very good example! I'll use it to prove my employees to
> give me some time for this problem. Thank you.
Please do. The situation you currently have is a technical debt and a
security hole in the system.
Just in case your bosses are more into Windows than into POSIX, you can
compare the situation with the %ProgramFiles% hierarchy of Windows
for which regular users do not have write access for the same reasons.
Reply to: