The proper way of group creation during package install

dviktor · 2018-10-26 14:44:32

Hi all! I found some threads here about user creation during installation of user-produced package (via makepkg, e. g.) but still have some questions.

My software installation should rest in /opt directory and its' directories must have special ownership: the user is "root" and the group is "compute"
By default there is no "compute" group so I think it's fine to create one during installing my package. I know that PKGBUILD processing occurs in fakeroot and because of this I should create needed group during .install-scripts. What is the proper way to create new group - using post_install() or pre_install()? Is simple "groupadd compute" will be enough?

In wireshark's source tree I see file wireshark.sysusers with the following:

g wireshark 150 - -

Is it the new mechanism of creating system groups?

Thank you for any advance

eschwartz · 2018-10-26 16:16:31

Yes, systemd-sysusers means the group will always be created if necessary during boot, it can be overridden if users wish to do so, and it's easy to find out what groups have been created by packages by reading the sysusers directory. It's also more lightweight than forking to bash to run a post-install script.

By the way, software which depends on the installation tree being owned by a given group sounds like a bad idea, is this part of some sort of internal update routine or something? There are limited use cases for specific binaries being like that, and obviously configuration directories, but in the general use case programs should not need to write to /opt...

dviktor · 2018-10-26 16:24:14

I make the package for one computational program which (sounds strange, yes) requires that only user and group permissions should be set and no flags for others (in case there are one of the rwx flags set for others this program refuses to run). Because some programs of this package write temporary info into their own root directory so end-user should have write access to these dirs too (program is started without sudo). So I've decided that creating separate "compute" group for this package would be good enough solution.

PS: this program doesn't respect any of POSIX rules. Also it is not using classic UNIX-like directory tree so we're forced to install everything into /opt directory

Thank you for the answer!

eschwartz · 2018-10-26 17:21:33

Naturally, this explanation makes a lot of sense, I've seen other programs just as badly behaved. The use of /opt is an unsubtle hint that this might be the case.

Using a "compute" group seems like a reasonable workaround. Hardcoding a gid in the package does have the potential for clashing with something else, and I think the closest you'll get to avoiding that, is to make sure you don't conflict anything in the https://wiki.archlinux.org/index.php/De … D_Database (which tracks UIDs/GIDs for the official repositories).

dviktor · 2018-10-26 17:55:47

I think that I can use automatic GID allocation for my "compute" group - the exact ID is not matter because I want to notify end-user with post-install echo message about the need to join newly created group

eschwartz · 2018-10-26 18:02:11

Hmm? In order for dynamic allocation to work, none of the packaged files or directories can be owned by the group, since you cannot know which gid the end-user machine will be allotted.

So, if it only needs ownership of an empty directory for data files, then you could create the directory using tmpfiles.d and the group using sysusers.d, and leave everything packaged in the package, owned by root:root

dviktor · 2018-10-26 18:16:13

But I want to remap owner of package files in post_install() script, after sysusers.d will be installed in system...

eschwartz · 2018-10-26 19:21:22

I guess you could, but the downside of this vs. a fixed gid is that the package files no longer match the state of the system. e.g. pacman -Qkk would report mismatched ownership.

Also changing ownership during post_upgrade has the potential, depending on unique circumstances, to open up security holes (the most obvious being that files can temporarily be owned by the wrong user who should not have permissions -- general advice is, make sure the packaged version is strictly owned by root, and that setuid/setgid if used are delayed until it's safe).

dviktor · 2018-10-26 20:49:41

So, explicitly setting root:GID during install for package files is considered good practice? If so, I will stay with that solution
Thank you for great explanation!

eschwartz · 2018-10-26 20:55:22

Yes, it's the ideal, preferred situation. Of course, the ideal preferred situation is to have an agreed-upon UID/GID for this -- but there's no central registry for UID/GID in AUR packages.

I know people have suggested it might be nice in the future, if pacman got native support for this, either by allocating a UID as part of the package metadata and updating the files to match, or (perhaps in combination with this) allowing pacman to store and extract the username:groupname rather than only using their numeric equivalents.

It's currently not the most polished area of the packaging format, but then, the whole situation is less than 100% ideal.

dviktor · 2018-10-26 20:57:38

Thank you a lot. Dealing with non-standard software packages is always a pain

Arch Linux

#1 2018-10-26 14:44:32

The proper way of group creation during package install

#2 2018-10-26 16:16:31

Re: The proper way of group creation during package install

#3 2018-10-26 16:24:14

Re: The proper way of group creation during package install

#4 2018-10-26 17:21:33

Re: The proper way of group creation during package install

#5 2018-10-26 17:55:47

Re: The proper way of group creation during package install

#6 2018-10-26 18:02:11

Re: The proper way of group creation during package install

#7 2018-10-26 18:16:13

Re: The proper way of group creation during package install

#8 2018-10-26 19:21:22

Re: The proper way of group creation during package install

#9 2018-10-26 20:49:41

Re: The proper way of group creation during package install

#10 2018-10-26 20:55:22

Re: The proper way of group creation during package install

#11 2018-10-26 20:57:38

Re: The proper way of group creation during package install

Board footer