Debians deb packages are simple things, all files the package is going to install is stored in an archive.

This archive contains the full tree of files, and also their permissions and ownership data. During install, the archive is extracted into the root filesystem as is.

An Example

The package fping contains an archive with the follwing files:

 /usr/bin/fping
 /usr/bin/fping6
 /usr/share/doc/fping/README
 /usr/share/doc/fping/changelog.Debian.gz
 /usr/share/doc/fping/changelog.gz
 /usr/share/doc/fping/copyright
 /usr/share/lintian/overrides/fping
 /usr/share/man/man8/fping.8.gz
 /usr/share/man/man8/fping6.8.gz

Permissions and owner data (with owner almost always beeing root) is only taken from the archive.

With that in mind, it is impossible to extract the archive with correct ownership preserved without having superuser privileges. Without any knowlegde of the inner workings of rpm and alien, i'd guess alien is extracting the source archive during convert.

Answering your questions:

How are the file ownerships different when run as root vs. a normal user?

Normal users can only create files they self own, and cannot change ownership of files.

Why does file ownership in a package matter?

Maybe it does, maybe it doesn't. Remember: Without beiing root, the files will be owned by the uid who converted the package. While not beeing good practice having unprivileged user install binaries in /usr/bin , it might work. But it will break when the stuff installed has to be owner by root.

Back to the example, fping needs to be setuid root to work -> package broken due wrong ownership.

blackhat.blade

Posted 2014-06-28T19:38:39.210

Reputation: 156

It is possible to extract ownership and permission information from file archives, so this answer doesn't really make sense unless we are assuming lazy programming. I'm betting it's simply because package managers are fairly intricate and it's hard to get a "translated" package reliably without allowing a higher level access than normal users have. – Heptite – 2014-06-29T01:58:04.130

@Heptite What do you mean by "extract" ownership information? As in reading the information like an ls -l displays? Alien is actually creating a files for the output .rpm file. Do they need to be created with the appropriate permissions within the .rpm itself, or is the file permissions problem handled when the package manager reads the package manifest to extract the files properly? – kdbanman – 2014-06-29T03:00:27.580

When RPM bundles a package, it reads file ownership and permissions and stores them in the archive. You can actually see the ownership and permissions within the archive without installing by doing rpm -qlvp package.rpm. This means that technically you could repackage files from an archive into a different archive (rpm to deb) without ever actually installing on the filesystem. My point is that there has to be another reason why alien doesn't do this (and needs root powers) than what this answer is saying. – Heptite – 2014-06-29T04:49:16.727

I don't think there is a hard requirement for superuser rights when repackaging in general. It is probably an implementation detail of Alien, guessing it extracts the package to some temporary dir, and then repack the contents. – blackhat.blade – 2014-06-29T09:44:21.837

3I would suspect to need root so you can apply the proper permissions on the new file so that they match the source. – Ƭᴇcʜιᴇ007 – 2014-06-28T19:40:52.257

@techie007 Thanks for sharing your suspicions! I don't think the ownership of the .rpm archive matters, though. More specifically, aren't the file permissions assigned by the package manager when it reads that information from the .rpm spec file during the extraction and installation process? – kdbanman – 2014-06-29T03:04:39.210

Why does the alien package converter need root permissions?

Answers

How are the file ownerships different when run as root vs. a normal user?

Why does file ownership in a package matter?