Hey,
What is the prefered way of creating users/groups and handling files ownership for AUR packages?
My take is to change the file ownership (`chown`) in .install script. That's what I do in the PKGBUILDs I write myself.
However, inspircd, which I adopted a few months ago takes a different approach. The previous maintainer hardcoded a UID and GID directly in the package:
PKGBUILD: install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
.install: getent group inspircd &>/dev/null || groupadd -r -g 141 inspircd getent passwd inspircd &>/dev/null || useradd -r -u 141 -g inspircd -d /var/lib/inspircd -s /bin/false inspircdl
I don't like this approach - what if the user has already assigned UID 141 to other user? Then effectively inspircd and, say, Apache, are running under the same user. But maybe there is some reason behind this approach that I'm not aware of.
Thanks for your help.
On Sat, Jan 25, 2014 at 4:03 PM, Nowaker enwukaer@gmail.com wrote:
Hey,
What is the prefered way of creating users/groups and handling files ownership for AUR packages?
My take is to change the file ownership (`chown`) in .install script. That's what I do in the PKGBUILDs I write myself.
However, inspircd, which I adopted a few months ago takes a different approach. The previous maintainer hardcoded a UID and GID directly in the package:
PKGBUILD: install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
.install: getent group inspircd &>/dev/null || groupadd -r -g 141 inspircd getent passwd inspircd &>/dev/null || useradd -r -u 141 -g inspircd -d /var/lib/inspircd -s /bin/false inspircdl
I don't like this approach - what if the user has already assigned UID 141 to other user? Then effectively inspircd and, say, Apache, are running under the same user. But maybe there is some reason behind this approach that I'm not aware of.
Thanks for your help.
-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
The reason why permissions should be set in the PKGBUILD is because that way pacman can track them. Then it's up to the maintainer to choose UIDs/GIDs that do not conflict with official packages, and to the user to check that they don't already use that particular UID/GID ,before installing an AUR package.
Cheers,
Maxime Gauduin wrote:
The reason why permissions should be set in the PKGBUILD is because that way pacman can track them. Then it's up to the maintainer to choose UIDs/GIDs that do not conflict with official packages, and to the user to check that they don't already use that particular UID/GID ,before installing an AUR package.
Cheers,
Maxime
I just want to add that I think hard-coding UIDs and GIDs is a very bad idea. I would expect them to vary across systems.
No, I do not have a better suggestion.
Regards, Xyne
The reason why permissions should be set in the PKGBUILD is because that way pacman can track them.
Interesting. I didn't know Pacman could do that. The phrases "UID", "uid" and "gid" do not appear in the man pages for pacman or pkgbuild. Is this undocumented behaviour?
Then it's up to the maintainer to choose UIDs/GIDs that do not conflict with official packages, and to the user to check that they don't already use that particular UID/GID ,before installing an AUR package.
Ick. I think that's an unnecessary and unreasonable expectation that results in a more fragile and unmaintainble system.
As for a better solution? Hmm. `install` (and probably other tools too) can reference user and group names directly. Thus, this:
install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
Could also be written as this:
install -o inspircd -g inspircd -dm750 "${pkgdir}/var/log/inspircd"
--Jeremy
On Mon, Jan 27, 2014 at 5:35 AM, Jeremy Audet ichimonji10@gmail.com wrote:
As for a better solution? Hmm. `install` (and probably other tools too) can reference user and group names directly. Thus, this:
install -o141 -g141 -dm750 "${pkgdir}/var/log/inspircd"
Could also be written as this:
install -o inspircd -g inspircd -dm750 "${pkgdir}/var/log/inspircd"
The problem with that is that the uid/gid for the permissions will be computed on the machine where the package is built, and there is no guarantee that the same uid/gid has the same name on another machine. Of course this isn't a problem if the package is only in the AUR, but it eliminates the option to prebuild the package (for inclusion in the official repositories, for instance).
If you want an example, I've attached a simple bash script that demonstrates the behaviour by referencing "uidgidtestuser1" when building the package, then renaming that user to "uidgidtestuser2". The script will output a PKGBUILD, build the package, run sudo and manipulate users and install/uninstall the package, so MAKE SURE YOU READ THE SCRIPT before you run it. I take no responsibility for any damage caused by running it.
/Emil Lundberg
On Mon, Jan 27, 2014 at 2:44 PM, Emil Lundberg lundberg.emil@gmail.com wrote:
Of course this isn't a problem if the package is only in the AUR, but it eliminates the option to prebuild the package (for inclusion in the official repositories, for instance).
Sorry for double posting, it struck me right after sending the last message that this also won't be a problem when there is a generally accepted standard uid/gid for the particular user/group in question.
/Emil Lundberg
As for a better solution? Hmm. `install` (and probably other tools too) can reference user and group names directly. Thus, this:
The problem with that is that the uid/gid for the permissions will be computed on the machine where the package is built, and there is no guarantee that the same uid/gid has the same name on another machine. Of course this isn't a problem if the package is only in the AUR, but it eliminates the option to prebuild the package (for inclusion in the official repositories, for instance).
It won't work for packages from AUR either. `install` would be called before .install script is able to useradd and groupadd. Only package updates would work.
I've attached a simple bash script
You forgot to attach the script or ML stripped it.
On Mon, Jan 27, 2014 at 6:53 PM, Nowaker enwukaer@gmail.com wrote:
You forgot to attach the script or ML stripped it.
Oops! I'll try attaching it again, if the ML strips it I'll just inline it.
As for a better solution? Hmm. `install` (and probably other tools too)
can reference user and group names directly. [...]
The problem with that is that the uid/gid for the permissions will be
computed on the machine where the package is built, [...]
It won't work for packages from AUR either. `install` would be called
before .install script is able to useradd and groupadd. Only package updates would work.
Aaah. What you are saying finally clicked, and I think I have a solution. My (possible?) solution relies on this point: all PKGBUILD functions must be runnable by `makepkg`, and all .install functions must be runnable by `pacman`. As a result: * One can perform system-independent actions in the PKGBUILD functions. This includes dictating where files should be installed. * One can perform system-dependent actions in the .install functions. This includes assigning an owner to a file (and, therefore, touching user IDs).
I've rewritten the inspircd package so that file ownership is assigned in the .install file. This change means user ID and group ID numbers are never explicitly stated. You can see the resultant package [1] and how it differs from the original. [2] I've tested the package on my machine, and it seems legit. Thoughts? By the way, namcap emits an enormous number of warnings, and inspircd fails to start via systemd. This occurs regardless of whether I use the existing or updated package. (and yes, I obeyed the dictates in the post_install message)
[1] https://github.com/Ichimonji10/PKGBUILDs/tree/inspircd/inspircd [2] https://github.com/Ichimonji10/PKGBUILDs/commit/8084208a93a625dd686b13da1d8a...
- One can perform system-independent actions in the PKGBUILD functions.
This includes dictating where files should be installed.
- One can perform system-dependent actions in the .install functions. This
includes assigning an owner to a file (and, therefore, touching user IDs).
I've rewritten the inspircd package so that file ownership is assigned in the .install file. This change means user ID and group ID numbers are never explicitly stated.
Yeah, I think this is the way to do it. I'm also surprised that no-one else in the thread (me included) thought to suggest it. :)
Note that you can use the -U option in useradd to also create a group by the same name, though I don't know how that behaves if the group already exists and the user does not.
I've rewritten the inspircd package so that file ownership is assigned in the .install file.
Thanks for reviving the thread. :) I too think useradd and groupadd in .install is the way to go, as I said in the first post. This has always worked for my packages well. Just inspircd, an adopted package, had it the other way and I wanted to ask the people on ML why.
inspircd fails to start via systemd
I will surely have a look. I use this package on three production machines, but maybe something broke in the meantime? I don't know. I will also reuse your PKGBUILD. Thanks.
Should this go to the AUR guidelines?
On Tue, Feb 4, 2014 at 3:35 PM, Nowaker enwukaer@gmail.com wrote:
I've rewritten the inspircd package so that file ownership is assigned in
the .install file.
Thanks for reviving the thread. :) I too think useradd and groupadd in .install is the way to go, as I said in the first post. This has always worked for my packages well. Just inspircd, an adopted package, had it the other way and I wanted to ask the people on ML why.
inspircd fails to start via systemd
I will surely have a look. I use this package on three production machines, but maybe something broke in the meantime? I don't know. I will also reuse your PKGBUILD. Thanks.
Should this go to the AUR guidelines?
-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
You might wanna have a look at this: https://bugs.archlinux.org/task/36770
Cheers,
You might wanna have a look at this: https://bugs.archlinux.org/task/36770
Yeah, but there's less packages in core/community than in AUR. Arch Linux Developers and TUs can agree on some UIDs and GUIDs so packages don't conflict. In AUR you can't. ;-) That's why I said "AUR guidelines", not "PKGBUILD guidelines".
Am 25.01.2014 17:13, schrieb Maxime Gauduin:
The reason why permissions should be set in the PKGBUILD is because that way pacman can track them. Then it's up to the maintainer to choose UIDs/GIDs that do not conflict with official packages, and to the user to check that they don't already use that particular UID/GID ,before installing an AUR package.
This is not optimal, but there's a list of UIDs and GIDs: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
Beyond that, there's two comments I have:
1) Software shouldn't really rely on files being owned/writable by certain users. An application is either a system service, which can adjust the needed permissions at runtime before dropping privileges - thus no need to hardcode uids or even user names. If the application is a user application, then it writes with the user's permissions anyway. If an admin wants a user application to run system-wide, it's his job to set up user and working directory.
In short: apart from very few system-specific groups, the package manager should not be involved here, and packages that need files owned by special non-root users should be fixed.
2) *If* we really need specific UIDs, then pacman should gain a feature where it translates ownership during package extraction.
Software shouldn't really rely on files being owned/writable by certain
users.
Sure, software shouldn't rely on files being owned/writable by *certain* users. But it's reasonable for software to rely on files being owned/writable by *a* user. Consider, for example, `mpd` and `subsonic`. Both programs are music servers, and therefore both programs do things like manipulate playlist files. (and keep a sqlite db of music info?)
If an admin wants a user application to run system-wide, it's his job to set up user and working directory.
That's a great ideal. However, it's an unrealistic expectation, IMO. There are likely users of Arch who: 1. Don't know that they are supposed to manually configure the permissions for their system services. 2. Do know that they are supposed to configure permissions, but still mess up. After all, it's easy to forget this step, doing things by hand is error-prone, and discovering the configuration process for each program requires some footwork (or, worse, trial and error!).
I've been using Arch for a while now (one year? two?), and have thusly inspired several acquaintances to give Arch a shot. One is a former system administrator who now works as a manager, and the other is a software engineer. When I tell them that `sudo` is not installed, or that `cronie` is not enabled by default, they laugh, but they get it: Arch doesn't hold your hand. But this will just blow their mind, because it completely breaks the principle of least surprise. "You mean to tell me that the program I just installed will run as root, *by default?*"
TL;DR: It is reasonable for programs to own certain files, and it is unreasonable to expect end users to make that happen.
aur-general@lists.archlinux.org