Unable to create user in PKGBUILD / fakeroot

foppe · 2013-04-03 12:21:57

tl;tr Package creation witk makepkg crashes if a certain user does not exist

I'm maintaining package Icinga [1] and I've had three comments about the way the pakage wants to install. Following the install from the official documentation [2] a user needs to be created. This will be the main user for the build process. Is built with [3]:

--with-icinga-user=${_icinga_user} \
--with-icinga-group=${_icinga_user} \

thus owning the main files to that user. This is a preferred e.g. suPhp [4][5] method where exposed (web/server) files are not owned by root or http but by a limited user. Apart from my ideas of a safe environment I want to be able to package an application the way it's intended by the creators.

I've investigated an researched a decent amount. I found [6] discussing the possibility of creating a user. One of the examples [7] tries to create a temporary user inside the fakeroot environment of build() and poackage():

  if [ -z $(getent passwd $_amandauser) ] ; then
    msg "Adding user/group (temporarily)"
    groupadd -g $_amandagid $_amandagroup
    useradd -u $_amandauid -g $_amandagroup -G storage,disk -m -d /var/amanda -s /bin/bash -c "Amanda Backup Daemon" $_amandauser
    _cleanup=1
  else
    _cleanup=0
  fi

but that fails as this snippet shows

$ faketroot
# groupadd -g 667 icinga
# groupadd: PAM: Authenticatie service kan geen authenticatie informatie ophalen

Interestingly emerge (Gentoo) has a function to add a user in pkg_setup() [8]

	enewgroup icinga
	enewuser icinga -1 -1 /var/spool/icinga icinga -c "icinga alert"

The only reference to such idea in the Arch world is a keyword in PKGBUILD [9] like

require_user('user1' 'user2')
require_group('group1')

What I did manage is removing all chown's from PKGBUILD, create a user in post_install() and chown several files to that user [10]. I would regard that a highly unsafe operation. Can anyone think of a better solution to be able to build() and later.package() an application when it's uncertain if a user exists? It might be helpful to exit makepkg in an early stage with a clear message (instructions to create the user) if that user doesn't exist.

[1] https://aur.archlinux.org/packages/icinga/
[2] http://docs.icinga.org/latest/en/quicks … ateaccount
[3] https://aur.archlinux.org/packages/ic/icinga/PKGBUILD
[4] http://www.suphp.org/Home.html
[5] https://wiki.archlinux.org/index.php/Suphp
[6] https://bbs.archlinux.org/viewtopic.php?id=105894
[7] https://aur.archlinux.org/packages/am/amanda/PKGBUILD
[8] https://271339.bugs.gentoo.org/attachment.cgi?id=287405
[9] https://wiki.archlinux.org/index.php/De … D_Database
[10] http://sprunge.us/XMgi?sh

Last edited by foppe (2013-04-03 13:56:41)

Lone_Wolf · 2013-04-03 20:45:32

The amada pkgbuild [7] seems to solve the non-existing user/group issue by advocating to run the entire makepkg as root.
Imo this is worse then using chown in post_install .

The developer wiki page [9] appears to be intended to create a list of 'official' users/groups , it seems unlikely user/group for aur packages will be added.

You could try using something like 'su --login --command ' for the groupadd/useradd commands.
This seems safer then running makepkg as root or using chown, but it will make the PKGBUILD interactive and that is frowned upon i think.

Checking for the existence early in he PKGBUILD and giving a clear message what needs to be done looks like the best option.

tdy · 2013-04-03 21:08:07

foppe wrote:

What I did manage is removing all chown's from PKGBUILD, create a user in post_install() and chown several files to that user [10]. I would regard that a highly unsafe operation.

This is the approach I've used in several packages. What specifically are you worried about safety-wise?

foppe · 2013-04-03 21:40:17

tdy wrote:

foppe wrote:
What I did manage is removing all chown's from PKGBUILD, create a user in post_install() and chown several files to that user [10]. I would regard that a highly unsafe operation.
This is the approach I've used in several packages. What specifically are you worried about safety-wise?

I messed up most of my root through a tiny error, soimething like

chown -R icinga:icinga /

I'd rather be working inside the safe environment of the package folder /chroot doing my chowns.

foppe · 2013-04-03 21:48:19

Lone_Wolf wrote:

The developer wiki page [9] appears to be intended to create a list of 'official' users/groups , it seems unlikely user/group for aur packages will be added.

I read it as a requirement for certain user/group to exist.

Lone_Wolf wrote:

Checking for the existence early in he PKGBUILD and giving a clear message what needs to be done looks like the best option.

I actually think this is the best if not only approach, apart from the Gentoo solution.

I'll investigate a construction like

getent group ${_icinga_group} >/dev/null || cat <<EOF
  Please create user blah blah
EOF
&& exit

But will do that tomorrow.

foppe · 2013-04-04 16:49:44

I came up with

build() {
  if [ -z $(getent group icinga) -a $(getent passwd icinga) ]
    then 
    cat << DOC 
--> This script requires user icinga:icinga to exist
--> You can use the following commands to do create this user:
# groupadd -g 667 icinga
# useradd -u 667 -g icinga -G http -d /dev/null -s /bin/false icinga
DOC
   exit
  fi

being the overall best solution. If anyone has a smarter idea please let me know.
I edited the Wiki entry accordingly [1]

[1] https://wiki.archlinux.org/index.php/Ic … stallation

Last edited by foppe (2013-04-04 16:51:19)

tdy · 2013-04-04 17:39:14

Personally I dislike that approach and don't feel like this is how PKGBUILDs are meant to be written. It's similar to people who like to put interactive prompts in the build() function.

The only thing "unsafe" about doing this automatically in post_install() is that you accidentally made a mistake. That's not a reason to dump this in build(). Packagers need to be careful of everything they put in an .install file.. that's not a real justification for disrupting the build() flow like this for the end user.

Of course, I'm not a makepkg dev, so take this for what it's worth.

foppe · 2013-04-04 18:50:23

tdy wrote:

Personally I dislike that approach and don't feel like this is how PKGBUILDs are meant to be written. It's similar to people who like to put interactive prompts in the build() function.

Your point is valid. I don't particular like it either. I'm making another choice though. The user needs to be created either manually or hackish but automagically.

tdy wrote:

The only thing "unsafe" about doing this automatically in post_install() is that you accidentally made a mistake. That's not a reason to dump this in build(). Packagers need to be careful of everything they put in an .install file.. that's not a real justification for disrupting the build() flow like this for the end user.

I regard chmodding recursively (and rm-ing for that matter) on the filesystem inherently unsafe. My point is that I want to do it (and can!) inside the 'safe' build and package environment. The makepkg environment is meant for that. That's why makepkg is run as user, not as root. If it were run as root I'd be able to create the user.

Last edited by foppe (2013-04-04 19:36:02)

progandy · 2013-04-04 19:22:27

foppe wrote:

tdy wrote:
Personally I dislike that approach and don't feel like this is how PKGBUILDs are meant to be written. It's similar to people who like to put interactive prompts in the build() function.
Your point is valid. I don't particular like it either. I'm making another choice though. The user needs to be created either manually or hackish but automagically.

Would it work to create a LD_PRELOAD module that overrides the functions getpw..., setpw..., putpw... and the same for groups (e.g. getgr...) ? Then we could create fake users and use them in the makepkg-process. Then make sure the user exists before extracting the tar-file, e.g. use pre_install. (libarchive / bsdtar first tries the stored user-/groupname. Only if it doesn't exist the stored uid/gid is used.)

Last edited by progandy (2013-04-04 19:42:34)

foppe · 2013-04-04 19:51:32

progandy wrote:

Would it work to create a LD_PRELOAD module that overrides the functions getpw..., setpw..., putpw... and the same for groups (e.g. getgr...) ? Then we could create fake users and use them in the makepkg-process. Then make sure the user exists before extracting the tar-file, e.g. use pre_install. (libarchive / bsdtar first tries the stored user-/groupname. Only if it doesn't exist the stored uid/gid is used.)

That feels more like a feature request. But yes, creating a fake user during build() and package() would do. I can check for or create the actual user in pre_install().

progandy · 2013-04-05 05:22:27

foppe wrote:

progandy wrote:
Would it work to create a LD_PRELOAD module that overrides the functions getpw..., setpw..., putpw... and the same for groups (e.g. getgr...) ? Then we could create fake users and use them in the makepkg-process. Then make sure the user exists before extracting the tar-file, e.g. use pre_install. (libarchive / bsdtar first tries the stored user-/groupname. Only if it doesn't exist the stored uid/gid is used.)
That feels more like a feature request. But yes, creating a fake user during build() and package() would do. I can check for or create the actual user in pre_install().

I wanted to know whether my thoughts were realistic first
https://github.com/progandy/fakeuser

foppe · 2013-04-05 11:12:00

progandy wrote:

I wanted to know whether my thoughts were realistic first
https://github.com/progandy/fakeuser

tl;tr Works like a charm

git clone git://github.com/progandy/fakeuser.git
cd fakeuser
make
# Folder fakeuser contains libfakeuser.so and fakeadd
# Folder fakeuser/example-makepkg contains fakepkg
wget https://aur.archlinux.org/packages/ic/icinga/icinga.tar.gz
tar -zxf ./icinga.tar.gz
cd icinga
# Prepare MAKEPKG see [1]
# Mostly:
## fakeadd -G -n $_icinga_group -g 667
## fakeadd -U -n $_icinga_user -u 667 -g 667
# Prepare icinga.install see [2] - created group/user icinga:icinga in pre_install()

# Make sure the user icinga:icinga doesn't exist
sudo userdel icinga
sudo groupdel icinga

# copy fakepkg
cp ../example-makepkg/fakepkg .

# run fakepkg instead of makepkg
./fakepkg
# Works like a charm

# installing package
sudo pacman -U icinga-1.8.4-2-x86_64.pkg.tar.xz

# test
ls -al /usr/share/webapps/icinga
# drwxrwxr-x 10 icinga icinga 4096  5 apr 12:37 .
# drwxr-xr-x  3 root   root   4096  5 apr 12:37 ..
# drwxr-xr-x  2 icinga icinga 4096  5 apr 12:37 cgi-bin
# <snip>
# drwxrwxr-x  2 icinga icinga 4096  5 apr 12:37 ssi
# drwxrwxr-x  2 icinga icinga 4096  5 apr 12:37 stylesheets

ls -al /var/spool/icinga
# drwxr-xr-x  4 icinga icinga 4096  5 apr 12:37 .
# drwxr-xr-x 10 root   root   4096  5 apr 12:54 ..
# drwxrwxr-x  2 icinga icinga 4096  5 apr 12:37 checkresults
# drwxr-xr-x  2 icinga icinga 4096  5 apr 12:37 rw


# [1] http://sprunge.us/ISjA?sh
# [2] http://sprunge.us/PUPI?sh

I used a modified PKGBUILD [1] plus a modified icinga.install [2]. The PKGBUILD adds the fakeuser

package() {
  fakeadd -G -n $_icinga_group -g 667
  fakeadd -U -n $_icinga_user -u 667 -g 667
  cd "$srcdir/$pkgname-$pkgver"

The icinga.install file adds the read user in pre_install()

pre_install() {
	_icinga_user="icinga"
	_icinga_group="icinga"
	_icinga_gid=667
	_icinga_uid=667

	getent group icinga > /dev/null || groupadd -g $_icinga_gid $_icinga_group > /dev/null
	getent passwd icinga > /dev/null || useradd -u $_icinga_uid -g $_icinga_group -G http \
		-d /dev/null -s /bin/false $_icinga_user > /dev/null	
}

and this is exacly what I think is the very best solution to solve this issue. It's completely safe because all tricky file manipulation is done in a fakeroot environment and it's completely hassle free for the end-user.
Heads up. Let's try get this idea upstream

[1] http://sprunge.us/ISjA?sh
[2] http://sprunge.us/PUPI?sh

Last edited by foppe (2013-04-05 11:17:33)

ackalker · 2013-04-05 18:40:23

Nifty solution, fakeuser. It does need changes to makepkg with regards to fakeroot.
Since packages which require a non-standard user / group to exist prior to building are so rare, what is wrong with (make)depend'ing on a dummy package which does nothing more than create this user / group?

Don't get me wrong, I do think fakeuser is a very nice solution, I just don't think there's tons of motivation for the Arch devs to patch up makepkg and/or fakeroot just for creating non-standard users / groups from within a fakeroot environment.

Last edited by ackalker (2013-04-05 18:50:30)

hobarrera · 2013-04-20 00:27:47

You must use an install file (for example, with pre_install, as suggested above).

Creating a user in the PKGBUILD will create the user on the machine that BUILDS the package, not on the one that installs it. So the package will fail to install, unless it's been built on the target machine at some point.

Lone_Wolf · 2013-04-20 11:28:25

hobarerra, that doesn't solve the problem of the user/group that needs to be present DURING build.

The fakeuser part takes care of that by creating a temp user/group for building only.
Check post #10 and you'll see that foppe is aware of the need of an install file with pre_install to create the real user/group.

hobarrera · 2013-04-20 12:47:14

Ooops, I misunderstood then.
I'm rather curious though; what's the justification for requiring a dedicated user/group for BUILDING?

Last edited by hobarrera (2013-04-20 12:47:23)

progandy · 2013-04-20 16:11:53

hobarrera wrote:

Ooops, I misunderstood then.
I'm rather curious though; what's the justification for requiring a dedicated user/group for BUILDING?

You don't need a group for the building, but for the packaging process it is beneficial.
The tar-package stores user/group names, so when you have the group during the packaging process you can do chown/chgrp here in a fakeroot instead of using post_install to modify the filesystem as root with recursive commands.

Last edited by progandy (2013-04-20 16:12:41)

hobarrera · 2013-04-25 14:54:11

progandy wrote:

hobarrera wrote:
Ooops, I misunderstood then.
I'm rather curious though; what's the justification for requiring a dedicated user/group for BUILDING?
You don't need a group for the building, but for the packaging process it is beneficial.
The tar-package stores user/group names, so when you have the group during the packaging process you can do chown/chgrp here in a fakeroot instead of using post_install to modify the filesystem as root with recursive commands.

Oh. Thanks.
In that case, you need to make sure that the UID/GID from the installation process match those created when installing the package as well. There's always a chance for collision.

Arch Linux

#1 2013-04-03 12:21:57

Unable to create user in PKGBUILD / fakeroot

#2 2013-04-03 20:45:32

Re: Unable to create user in PKGBUILD / fakeroot

#3 2013-04-03 21:08:07

Re: Unable to create user in PKGBUILD / fakeroot

#4 2013-04-03 21:40:17

Re: Unable to create user in PKGBUILD / fakeroot

#5 2013-04-03 21:48:19

Re: Unable to create user in PKGBUILD / fakeroot

#6 2013-04-04 16:49:44

Re: Unable to create user in PKGBUILD / fakeroot

#7 2013-04-04 17:39:14

Re: Unable to create user in PKGBUILD / fakeroot

#8 2013-04-04 18:50:23

Re: Unable to create user in PKGBUILD / fakeroot

#9 2013-04-04 19:22:27

Re: Unable to create user in PKGBUILD / fakeroot

#10 2013-04-04 19:51:32

Re: Unable to create user in PKGBUILD / fakeroot

#11 2013-04-05 05:22:27

Re: Unable to create user in PKGBUILD / fakeroot

#12 2013-04-05 11:12:00

Re: Unable to create user in PKGBUILD / fakeroot

#13 2013-04-05 18:40:23

Re: Unable to create user in PKGBUILD / fakeroot

#14 2013-04-20 00:27:47

Re: Unable to create user in PKGBUILD / fakeroot

#15 2013-04-20 11:28:25

Re: Unable to create user in PKGBUILD / fakeroot

#16 2013-04-20 12:47:14

Re: Unable to create user in PKGBUILD / fakeroot

#17 2013-04-20 16:11:53

Re: Unable to create user in PKGBUILD / fakeroot

#18 2013-04-25 14:54:11

Re: Unable to create user in PKGBUILD / fakeroot

Board footer