opkg standard practice re: ownership and permissions

[Daklu]

When installing files using opkg, we've noticed the owner assigned to the file on the target reflect the owner as they were set in the build environment. In other words, the files and directories on the target are owned by '1000', which is my UID on the build machine, instead of lvuser (UID=500 on my sbrio).

I'd rather not use post-install scripts to change the owner and permissions. Is the solution as simple as setting the owner to 500 on the build machine prior to creating the ipk, or do I need to create a 'lvuser' account on the build machine and make sure the UID=500 so it will match on the target?  Is there a standard way to accomplish this?

Follow up question: We noticed opkg overwrote the permissions and owner of the /home/lvuser/natinst directory, even though the directory existed previously. Does opkg automatically overwrite those properties of every directory in the file's path to match those of properties as they existed on the build machine, or is there some more advanced decision making that occurs there?

[BradM · Accepted solution]

Basically, the way that file and folder ownership works with .ipk files matches the underlying technology: tar. The files that  are meant to be installed when installing a package are compressed in a tarfile.

Normally, if you extract a tarfile as a normal user, the ownership of the contents of the tarfile are switched to your UID:GID.

However, when extracting the contents as admin/root (UID 0), it will try to maintain ownership. This ownership is kept in the tarfile as both a UID and a username. On extraction, it will attempt to match the username (this handles UIDs differing on different systems, as this would be a monumental headache for package management across distributions that don't have matching UIDs for system users) and, failing username lookup, will simply use the recorded UID for ownership.

With that background out of the way, there are a couple of options. What NI does internally is make use of a tool called pseudo (like sudo but different, gotta love the wit of opensource folks) that you use like sudo but records ownership not in your actual filesystem, but in a database. This is useful for setting ownership and then pseudo taring up the results (since you've recorded the ownership/permissions using pseudo, when tar querries that metadata, pseudo will report back what you've said). This is the more correct approach but a bit heavy-handed for a one-off need.

Another approach you can use is to use a so-called owner-map when creating the tar file (see https://www.gnu.org/software/tar/manual/html_section/tar_22.html)

Finally, you can indeed create a new user on your system that has the same username as the desired target username but, as noted above, it doesn't strictly need to have the same UID as the target system.

To the issue you'd noted about ownership of  the /home/lvuser/natinst directory, basically this all depends on how you're packaging up the tarfile, if you only point the tar creation command to just the files you want to put into the tarfile, it won't affect the directories. If, however, you tell tar to recursively include contents starting from a folder, it will include the folders into the archive as well, including the permisisons and ownership of those directories. There may be some options on archive creation that can change this behavior.

[metux]

---

@Daklu wrote:

When installing files using opkg, we've noticed the owner assigned to the file on the target reflect the owner as they were set in the build environment. In other words, the files and directories on the target are owned by '1000', which is my UID on the build machine, instead of lvuser (UID=500 on my sbrio).

The build/packaging process is just broken - the install stage needs to run in a fakeroot environment.

Professional embedded toolkits like ptxdist do that automatically.

(somebody offering proprietary binary kernel drivers is quite the opposite)