Correct way to set group to "games" in PKGBUILD

furrykef · 2024-02-26 06:02:45

I'm trying to package ReLarn for the AUR. The game keeps a high score table in a directory that's supposed to be accessible from multiple accounts, like NetHack does. Following NetHack's example, it seems the most appropriate thing to do is put the table in /var/games/larn and make sure that directory and the files in it are owned by root:games.

So right now I've got this in my PKGBUILD's package() function:

chown -R root:games "${pkgdir}/var/games"

It works fine when I install the package on my machine normally, but when I test the package in a chroot using `pkgctl build`, I get this error:

chown: invalid group: ‘root:games’

I understand this can be worked around by using 50 instead of games, but that makes the code less clear and it doesn't solve the underlying problem that the chroot doesn't have a group named games. I don't understand why not, and it makes me concerned that the games group might not exist on a user's machine. I added the filesystem package as a dependency since, as I understand it, that package is supposed to define the group, but that doesn't help.

I notice that some other packages in the AUR have the same problem, such as maelstrom-3.0.6-7. So if I do the same thing, I'd be in good company, but I'd rather do things the right way.

The nethack package (which is in Extra, not the AUR) doesn't error out when you run `pkgctl build`, but I'm not clear on how it works. It looks like a tmpfiles.d script is involved and I really have no idea what that's all about.

Lone_Wolf · 2024-02-26 11:52:27

No idea why the chroot doesn't accept that chown command, but I do know it's not how you're supposed to do things.

Getting permissions * ownership correct for temporary folders (like those under /var) is tricky, tmpfiles.d & systemd-tmpfiles are the mechanism systemd uses to deal with them.

Look at the nethack.tmpfiles content and use the man pages for tmpfiles.d and systemd.tmpfiles to understand what it does.

Once you understand how it works, write a snippet for ReLarn .

https://wiki.archlinux.org/title/System … rary_files may also be helpful .

furrykef · 2024-02-26 12:27:29

OK, I can do that if that's the correct way to do things, but I gotta ask…why?

Why is such a simple and obvious way of changing a file's group wrong? Why is the supposedly correct way so obscure and counterintuitive? Why isn't any of this documented anywhere I can find? (There are very few relevant mentions of tmpfiles in relation to packaging on the wiki, and the most relevant one seems to be "Web application package guidelines"…and this isn't a web application.) And how on earth is the average AUR package maintainer supposed to get this right?

loqs · 2024-02-26 12:33:52

Lone_Wolf wrote:

No idea why the chroot doesn't accept that chown command

Because the games group is created by systemd-sysusers so requires the systemd package to be in makedepends to use that group.

Lone_Wolf · 2024-02-26 12:52:58

/var/games was used a lot in the past (like 10+ years ago) but the vast majority of applications have switched to storing user data under $HOME .(and using cloud storage for stuff that needs to be shared with other users).

systemd & xdg base directory specification both played a big role in this.

Nethack basic design was done in the 20th century and never adapted to the modern specs. Relarn is described as a roguelike, so it's no surprise it follows the same scheme as nethack.

I do remember building vulture for nethack fork with 3D isometgric view (might even have maintained an aur package for it a decade or more ago) but that was the last time I had to deal with it.

And how on earth is the average AUR package maintainer supposed to get this right?

This is not something the average aur package manager is likely to encounter. Incase they do, they should do what you have done : ask for help.

furrykef · 2024-02-26 13:24:32

You still haven't answered my other question, though, which is, what makes the chown method so wrong? Why does tmpfiles.d need to be involved at all?

Lone_Wolf wrote:

/var/games was used a lot in the past (like 10+ years ago) but the vast majority of applications have switched to storing user data under $HOME .(and using cloud storage for stuff that needs to be shared with other users).

Well, $HOME is clearly the wrong place to store a high score table since it's supposed to have everyone's scores, not just the current user's. Storing them online is probably indeed the norm these days, but that requires having somewhere to upload them to, and not every developer wants to bother with that. I suspect the main reason this rarely comes up is high scores aren't especially common in games at all nowadays, but for those games that do have them and do store them offline, I think /var/games/foo is the proper place to do it.

Lone_Wolf wrote:

This is not something the average aur package manager is likely to encounter.

Well…this is my very first AUR package, so I guess I'm quite a statistical anomaly, then.

Lone_Wolf wrote:

Incase they do, they should do what you have done : ask for help.

From what I've seen, though, what they actually do is what I nearly did: use the chown method and call it a day.

Last edited by furrykef (2024-02-26 13:25:49)

Scimmia · 2024-02-26 13:51:46

since the games group has a defined, static GID, and /var *isn't* for temporary files, there is nothing wrong with using chown/

furrykef · 2024-02-26 22:16:42

Well, aside from the fact it doesn't play nice with `pkgctl build` without adding a strange dependency on systemd. Why is systemd responsible for creating this group?

I'm going to draw a line in the sand here: using tmpfiles.d for this is madness. Even if it is for some reason (which still has yet to be specified) the right way to do it now, there is no way this is even close to the Right Thing in the grand scheme of things. tmpfiles.d is supposed to be for managing temporary files. It's in the name! There's certainly no reason these files should need to be managed by a service. They should be created once and then the system can forget about it.

"There is more than one way to do it" is an OK philosophy. "There should be one—and preferably only one—obvious way to do it" is, IMO, better. But what Lone_Wolf's posts imply here is "There is one right way to do it, and it's obscure, unintuitive, and undocumented." I don't find that acceptable.

Last edited by furrykef (2024-02-27 04:21:20)

loqs · 2024-02-26 23:16:02

furrykef wrote:

Why is systemd responsible for creating this group?

Because systemd-sysusers is provided by the systemd package. The only group in /etc/group as shipped by filesystem is the root group. All other groups are created by systemd-sysusers.

Lone_Wolf · 2024-02-27 15:03:32

I may have been wrong about tmpfiles being the proper way for setting up folders under /var .

As for obscure & unintuitive :
in my opinion a large part of systemd is like that. The only ones that can answer why it's setup the way it is are its creators..

furrykef · 2024-03-01 00:35:18

After researching and experimenting further, it's become apparent to me that the purpose of using tmpfiles.d for this sort of thing is likely that it's simply shorter and easier than the equivalent shell script. So my impression now is that it's not the One True Way to do it, but it's nonetheless handy, if still unclear and unintuitive to the uninitiated. For this specific package, I'm inclined to handle the group and the directories with a post_install() script like this:

post_install() {
    # Create games group if it doesn't already exist
    # GID is from https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database
    groupadd -f -g 50 games

    # Put main executable in games group
    # This isn't done in package() because that group may not exist yet
    chown root:games /usr/lib/relarn/relarn.bin

    # Create the scoreboard if it doesn't already exist
    # and make sure it has correct group and permissions
    if [ ! -d /var/games ]; then
        mkdir -p /var/games
        chmod 775 /var/games
        chown root:games /var/games
    fi
    cd /var/games
    mkdir -p relarn
    chmod 775 relarn
    touch -a relarn/Relarn-scoreboard
    chmod 664 relarn/Relarn-scoreboard
    chown -R root:games relarn
}

post_upgrade() {
    # Make sure main executable is still in games group
    chown root:games /usr/lib/relarn/relarn.bin
}

It is a little long, though.

By the way, since this isn't an AUR-specific issue, perhaps this thread should be moved to the Creating & Modifying Packages subforum. I'm new here and wasn't paying attention to what subforums there were when I posted this thread. Sorry about that. ^^;

Abzie · 2024-03-11 11:45:30

A few pointers from your code above:

    # Create games group if it doesn't already exist
    # GID is from https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database
    groupadd -f -g 50 games

groupadd -f forces creation, so this will create the group again. The preferred method is creating a `relarn.sysusers` file and include it in your PKGBUILD.

This section can be done slightly better in the package() section of your PKGBUILD.

    # Put main executable in games group
    # This isn't done in package() because that group may not exist yet
    chown root:games /usr/lib/relarn/relarn.bin

    # Create the scoreboard if it doesn't already exist
    # and make sure it has correct group and permissions
    if [ ! -d /var/games ]; then
        mkdir -p /var/games
        chmod 775 /var/games
        chown root:games /var/games
    fi
    cd /var/games
    mkdir -p relarn
    chmod 775 relarn
    touch -a relarn/Relarn-scoreboard
    chmod 664 relarn/Relarn-scoreboard
    chown -R root:games relarn
}

I can't see that you've uploaded your PKBUILD to the AUR yet so I am assuming a few options below... Also add `relarn/Relarn-scoreboard` to your backup section or your scoreboard will get wiped on each update. You can chown to uid's and gid's, rather than usernames or group names.

PKGBUILD:

pkgname=relarn
pkgver=2.2.2
pkgrel=1
...
backup=(var/games/relarn/Relarn-scoreboard)
...
source=("https://gitlab.com/relarn/relarn/-/archive/release-2.2.2/relarn-release-2.2.2.tar.gz"
        'relarn.sysusers')
sha256sums=('xyz1'
            'xyz2')

build() {
...
}

package() {
...
    # Put main executable in games group
    chown root:50 "$pkgdir"/relarn/relarn.bin

    # Create the scoreboard if it doesn't already exist
    # and make sure it has correct group and permissions
    install -Ddm 775 -o 0 -g 50 "$pkgdir"/var/games/relarn
    install -Dm 664 -o 0 -g 50 /dev/null "$pkgdir"/var/games/relarn/Relarn-scoreboard

    install -Dm 644 relarn.sysusers "$pkgdir"/usr/lib/sysusers.d/relarn.conf
}

relarn.sysusers:

g games 50 - -

post_upgrade() section is uneeded.

ETA: would it be worth running a a separate user, rather than root? You can add a user into the .sysusers file and amend any init script / sytemd service unit to run as that user.
EDIT2: changed chown/chmod to install

Last edited by Abzie (2024-03-11 12:18:44)

loqs · 2024-03-11 12:36:18

For comparison a sysusers / tmpfiles only approach could look like:

pkgname=relarn
pkgver=2.2.2
pkgrel=1
...
backup=(var/games/relarn/Relarn-scoreboard)
...
source=("https://gitlab.com/relarn/relarn/-/archive/release-2.2.2/relarn-release-2.2.2.tar.gz"
        'relarn.sysusers'
        'relarn.tmpfiles')
sha256sums=('xyz1'
            'xyz2')

build() {
...
}

package() {
...
  # install systemd-sysusers
  install -Dm0644 $pkgname.sysusers \
    "${pkgdir}/usr/lib/sysusers.d/$pkgname.conf"

  # install systemd-tmpfiles
  install -Dm0644 $pkgname.tmpfiles \
    "${pkgdir}/usr/lib/tmpfiles.d/$pkgname.conf"
}

Last edited by loqs (2024-03-11 12:45:14)

furrykef · 2024-03-12 07:11:45

Abzie wrote:

groupadd -f forces creation, so this will create the group again.

It shouldn't. According to the manpage, "This option causes the command to simply exit with success status if the specified group already exists." In this case, the alias --force is misleading. I've also verified this behavior by looking at the source code for groupadd.

The preferred method is creating a `relarn.sysusers` file and include it in your PKGBUILD.

Hmm. I haven't seen this approach taken. It seems to be overkill for creating just one group.

This section can be done slightly better in the package() section of your PKGBUILD.

How? The games group may not exist when the package is installed (as I pointed out in a comment in the code you quoted). Granted, that's really unlikely, since I believe it should be created when systemd is installed, but I have heard of users removing them (because they think they'll never run games on that machine, but people do change their minds). Maybe this is paranoid thinking…

I can't see that you've uploaded your PKBUILD to the AUR yet

Correct. I found a couple unrelated issues I considered showstoppers, so I am working with upstream to hopefully make a 2.2.3 release that addresses them before uploading an AUR package. This is taking longer than I initially thought, but that release will also be a bit more featureful than I initially thought.

Also add `relarn/Relarn-scoreboard` to your backup section or your scoreboard will get wiped on each update.

That is one reason why I touch the file in post_install() instead of creating it in package(). That way it should never be overwritten or deleted.

You can chown to uid's and gid's, rather than usernames or group names.

Yes, but if the group exists, that should not be necessary. If the group doesn't exist, trying to use its gid anyway seems icky.

post_upgrade() section is uneeded.

I believe it is needed in the script as I currently have it. My understanding is post_upgrade() is run instead of, not in addition to, post_install(), and if pacman installed a new copy of relarn.bin during an upgrade, I don't expect it to have the correct group set because its group is not set in the packaging stage.

ETA: would it be worth running a a separate user, rather than root? You can add a user into the .sysusers file and amend any init script / sytemd service unit to run as that user.

I'm not sure I understand this suggestion.

Last edited by furrykef (2024-03-12 07:12:10)

Abzie · 2024-03-12 09:14:18

furrykef wrote:

It seems to be overkill for creating just one group.

Your thread is asking for the correct way to set up a group. This is the preferred method to do so in a PKGBUILD.

furrykef wrote:

That way it should never be overwritten or deleted.

Neither will it with being added to the backup= section

furrykef wrote:

trying to use its gid anyway seems icky

chown extrapolates a given group name to gid anyway - if you remove a user, you'll find their files have their uid/gid on them.

furrykef wrote:

I don't expect it to have the correct group set because its group is not set in the packaging stage.

If you package the program correctly by using the example given, you don't need to do this, hence, uneeded.

furrykef wrote:

I'm not sure I understand this suggestion.

All indications suggest you're running this game/program as root. You should be running as an application-specific and separate user. You can add this to your relarn.sysusers file and then amend the PKGBUILD install commands with the correct ownership.

furrykef · 2024-03-12 18:32:15

I'm going to address your last point first since it shows I may not have been sufficiently clear about my objectives.

Abzie wrote:

All indications suggest you're running this game/program as root.

What indications are those?? (Not a rhetorical question; I'm really curious what led you to believe this.) I'm honestly a little insulted by the suggestion that I would be so ignorant as to package a non-administrative program and require it to be run as root. The entire point of all this business with the games group (and therefore this thread) is to avoid running the game as root.

So let me break it down: relarn creates a high score table in a central location (/var/games/relarn). The game needs write access to this file regardless of which user is running the game. We could run the game as root, but we know that's bad, so we don't. Instead, we use a standardized group called games and make sure the high score table is in this group. Then we run relarn's executable in that group (by setting its group to games and setting its setgid bit) so that it will have write access to the scoreboard file even though it is being run as the same user who launched the program.

Arch's NetHack package and several other game packages do the same thing. The only thing I'm doing differently is I'm trying to ensure the games group actually exists before doing anything with the group.

To summarize, what I ideally want is:

A high score table to exist in a central location (i.e., not in a user's home folder)
For the game to be able to write to this table regardless of which user is running the program
Toward the above ends, to put the table in the games group and to run the game as that group (whether via setgid or some other means)
To avoid errors caused by this group not existing when package() is called
To avoid installing the package without the group existing
To avoid abusing programs like tmpfiles.d for situations it wasn't intended for and which aren't documented on the wiki

OK, taking the rest of your points in order…

Your thread is asking for the correct way to set up a group.

Well, kind of. The issue is the group is already supposed to be there, but it's not 100% guaranteed to be, and in a clean chroot, it isn't unless you have systemd as a dependency. Even if you do list systemd as a dependency, the user might've deleted the group or something.

Maybe this seems like an insane amount of effort worrying about an unrealistic scenario. That's kind of my point, though…it shouldn't be hard to do the Right Thing™. I may be a little guilty of bikeshedding here, but I'm trying my best to find a Right Thing solution that doesn't involve jumping through hideous hoops.

[using sysusers.d] is the preferred method to [set up a group] in a PKGBUILD.

Preferred according to whom? sysusers.d is scarcely mentioned on the wiki. Also, I don't think it solves the problem of the group possibly not existing at the time package() is run. That is to say, if the group does not exist, this is still invalid in the package() function:

install -Dm0644 $pkgname.sysusers "${pkgdir}/usr/lib/sysusers.d/$pkgname.conf"
install -Dm0775 -g games foobar "$pkgdir/var/games/$pkgname/foobar"

…because the .sysusers file isn't actually installed yet when the second line is run. So I'm not clear on what problem using sysusers.d instead of groupadd actually solves here.

furrykef wrote:
That way it should never be overwritten or deleted.
Neither will it with being added to the backup= section

Well, it only needs to be in the backup section if it's packaged in the first place. However, I'm struggling to recall now why I did not like this solution when I first wrote my PKGBUILD; I concede my reasoning may have been mistaken. Maybe the Relarn-scoreboard file can be packaged after all.

furrykef wrote:
trying to use its gid anyway seems icky
chown extrapolates a given group name to gid anyway - if you remove a user, you'll find their files have their uid/gid on them.

I know this, but something seems fundamentally wrong with using a gid to circumvent a nonexistent group. The group is supposed to exist, and if it does, you can use it by name.

Last edited by furrykef (2024-03-12 18:33:41)

Abzie · 2024-03-12 19:50:42

furrykef wrote:

What indications are those?

You are trying to change ownership of files and/or folders to root:games in your PKGBUILD, why aren't you chown'ing to the process the program will run as?

Surely `chown -r relarn:games` would be better than `chown -r root:games`? I don't understand why you feel insulted when you are asking for help...

furrykef wrote:

So let me break it down

OK, now you have explained what you are trying to achieve, replace the line from my earlier suggestion with:
install -Dm2775 -o 0 -g 50 /dev/null "$pkgdir"/var/games/relarn/Relarn-scoreboard

This will install the file to the correct location within the package with the correct permissions and setgid, and coupled with the backup= line, will prevent it from being overwritten by updates.

furrykef wrote:

Preferred according to whom?

The manpages.

systemd-sysusers uses the files from sysusers.d directory to create system users and groups and to add users to groups, at package installation or boot time.

Emphasis mine, from https://man.archlinux.org/man/sysusers.d.5.en

furrykef wrote:

I'm not clear on ... using sysusers.d instead of groupadd

The sysusers file is parsed at the end of the pacman transaction, adding the users/groups that were declared in the file. As you now know, uid's/gid's can be set without those users or groups explicitly being present on the system in /etc/passwd or /etc/group. Any unneeded users/groups created by your package are also cleared up when the package is uninstalled, something that wouldn't happen if you had run groupadd during your postinstall() section. You may be able to get away with running groupdel in your post_remove() section, but I'm sure others would add this is bad practice.

furrykef wrote:

only needs to be ... if it's packaged in the first place

If it's a file that the program does not create itself, but expects to be there at runtime - should be included within the package with the correct permissions, above.

furrykef wrote:

nonexistent group

There can be many reasons where a group has not been defined in /etc/group. If the group doesn't exist in /etc/group, then sysusers will create it and clean it up if you remove the package and the group is also not required by any other package.

Last edited by Abzie (2024-03-12 20:12:14)

loqs · 2024-03-12 20:10:42

Abzie wrote:

Any unneeded users/groups created by your package are also cleared up when the package is uninstalled, something that wouldn't happen if you had run groupadd during your postinstall() section.

Users and groups are never removed as there is no way to know if there any files/directories using the ID for that user/group that could then be reused in the future by newly created users/groups which is a potential vulnerability. So users/groups are left as permanent tombstone markers for the system administrator to manually clean up after they have checked if there are any files/directories with that ownership.

Abzie · 2024-03-12 20:16:09

loqs wrote:

could then be reused

Huh, good point - I didn't think of the implications in that way, I wrongly assumed it would have been cleared up at removal in a similar fashion to tmpfiles.

furrykef · 2024-03-13 04:41:43

Abzie wrote:

You are trying to change ownership of files and/or folders to root:games in your PKGBUILD, why aren't you chown'ing to the process the program will run as?
Surely `chown -r relarn:games` would be better than `chown -r root:games`?

root is the correct owner for most permanent files installed in /usr and /var. Most programs are owned by root but run as the user who launched the program, and those programs can happily read from files in those locations even if their owner is root so long as the permissions are set correctly. They can't write to them, of course, which is why in this case we are using the games group, which is an established solution to the problem for games.

Note that files created in both package() and in post_install() are owned by root by default. I would wager almost all of the files installed by your own PKGBUILDs are owned by root—as they probably should be.

I don't understand why you feel insulted when you are asking for help...

Well, I apologize for taking offense. But running a game as root is dangerous, and packaging a game to be used that way would be extremely irresponsible since it would spread that danger to others. If I saw a PKGBUILD author trying to do this, I would steer them away from trying to write packages until they've become more familiar with the Linux ecosystem.

OK, now you have explained what you are trying to achieve, replace the line from my earlier suggestion with:
install -Dm2775 -o 0 -g 50 /dev/null "$pkgdir"/var/games/relarn/Relarn-scoreboard
This will install the file to the correct location within the package with the correct permissions and setgid, and coupled with the backup= line, will prevent it from being overwritten by updates.

The scoreboard file should be 0664, not 2775. It's not executable, and the setgid bit is needed for the process that writes to the file (/usr/lib/relarn/relarn.bin), not for the file itself.

But aside from that, if indeed we wish to package the scoreboard file (and by now I'm inclined to agree that we do), then that install line looks fine (though the -o 0 is redundant).

The sysusers file is parsed at the end of the pacman transaction, adding the users/groups that were declared in the file. As you now know, uid's/gid's can be set without those users or groups explicitly being present on the system in /etc/passwd or /etc/group.

As I already knew, not as I now know, but yeah.

Using the gid 50 instead of the named group "games" feels dirty to me because the gid should be an implementation detail that is only used as a last resort since a group named "games" is already supposed to exist. I'm beginning to think that my use case may well be such a last-resort scenario, though.

Any unneeded users/groups created by your package are also cleared up when the package is uninstalled, something that wouldn't happen if you had run groupadd during your postinstall() section. You may be able to get away with running groupdel in your post_remove() section, but I'm sure others would add this is bad practice.

I certainly don't want to delete the group! It's a standard group that the user 99.9% probably already has set up. I'm just trying to handle that extra 00.1%. I'm seriously wondering if it's worth it, though. I may be letting the perfect be the enemy of the good.

furrykef · 2024-03-13 10:44:22

I think I've figured out another reason why tmpfiles.d is used to set permissions. It's because namcap will give errors (not warnings) for packages that have files with owners or groups it isn't expecting. So if you set the group on the files in package(), you get errors like this:

relarn E: File (usr/lib/relarn/relarn.bin) is owned by root:games
relarn E: File (var/games/relarn) is owned by root:games
relarn E: File (var/games/relarn/Relarn-scoreboard) is owned by root:games

I'm not clear on why namcap does this, though.

Arch Linux

#1 2024-02-26 06:02:45

Correct way to set group to "games" in PKGBUILD

#2 2024-02-26 11:52:27

Re: Correct way to set group to "games" in PKGBUILD

#3 2024-02-26 12:27:29

Re: Correct way to set group to "games" in PKGBUILD

#4 2024-02-26 12:33:52

Re: Correct way to set group to "games" in PKGBUILD

#5 2024-02-26 12:52:58

Re: Correct way to set group to "games" in PKGBUILD

#6 2024-02-26 13:24:32

Re: Correct way to set group to "games" in PKGBUILD

#7 2024-02-26 13:51:46

Re: Correct way to set group to "games" in PKGBUILD

#8 2024-02-26 22:16:42

Re: Correct way to set group to "games" in PKGBUILD

#9 2024-02-26 23:16:02

Re: Correct way to set group to "games" in PKGBUILD

#10 2024-02-27 15:03:32

Re: Correct way to set group to "games" in PKGBUILD

#11 2024-03-01 00:35:18

Re: Correct way to set group to "games" in PKGBUILD

#12 2024-03-11 11:45:30

Re: Correct way to set group to "games" in PKGBUILD

#13 2024-03-11 12:36:18

Re: Correct way to set group to "games" in PKGBUILD

#14 2024-03-12 07:11:45

Re: Correct way to set group to "games" in PKGBUILD

#15 2024-03-12 09:14:18

Re: Correct way to set group to "games" in PKGBUILD

#16 2024-03-12 18:32:15

Re: Correct way to set group to "games" in PKGBUILD

#17 2024-03-12 19:50:42

Re: Correct way to set group to "games" in PKGBUILD

#18 2024-03-12 20:10:42

Re: Correct way to set group to "games" in PKGBUILD

#19 2024-03-12 20:16:09

Re: Correct way to set group to "games" in PKGBUILD

#20 2024-03-13 04:41:43

Re: Correct way to set group to "games" in PKGBUILD

#21 2024-03-13 10:44:22

Re: Correct way to set group to "games" in PKGBUILD

Board footer