Arch Linux

You misinterpreted this bug. I am not asking for support, I am filing a bug against dhcpcd because the permissions on disk vary from what the package says should exists. I reference the forum because it says, if this happens, file a bug.

The package should really not be shipping it as 755 if tmpfiles always changes it to 700.

Well, I think this is a mismatch between upstream permissions and what we deploy on tmpfiles. I think the permissions on the fs are stricter and should be the ones used.

Change permissions on "$pkgdir/var/lib/dhcpcd/" to 700 to match those set by /usr/lib/tmpfiles.d/dhcpcd.conf.

Sorry if this is not the right place to ask or a dumb question, but out of curiosity: where is the 755 set in the package for /var/lib/dhcpcd?
In the source code I can only find that DBDIR=/var/lib/dhcpcd/ should be 750 an RUNDIR=/run/dhcp 755
https://github.com/rsmarples/dhcpcd/blob/master/src/dhcpcd.c#L2242

if (mkdir(DBDIR, 0750) == -1 && errno != EEXIST)
if (mkdir(RUNDIR, 0755) == -1 && errno != EEXIST)

it isn't created by the binary, it's created by make, so look at the makefiles.

It is created by [1]. The default mode used by install is 0755.

[1] https://github.com/rsmarples/dhcpcd/blob/master/src/Makefile#L85

Indeed, PKGBUILD passes --dbdir=/var/lib/dhcpcd to ./configure:
https://github.com/archlinux/svntogit-packages/blob/0dd530a20f81b2c5652738d71a9a2f781a3b2900/trunk/PKGBUILD#L42

And dhcpcd (make) creates the dir since 9.2.0:
https://github.com/rsmarples/dhcpcd/commit/bb7d64877674bd90b84c18364436d26351805a7e#diff-f57f2991a6aa25fe45d8036c51bf8b4dR85

It didn't do so in >= 9.0.0, < 9.2.0:
https://github.com/rsmarples/dhcpcd/commit/5f275b7bd1ed4d1f830b7a60ba253a98f7ef6127#diff-f57f2991a6aa25fe45d8036c51bf8b4dL85

Most likely owing to privilege separation (the daemon part running under a separate user?) being added in 9.0.0:
https://bugs.archlinux.org/task/66191
https://github.com/archlinux/svntogit-packages/commit/25dbad7bad390e40adb136cce37182e491f0dbed

And dhcpcd.tmpfiles was added in 9.0.0. Before that /var/lib/dhcpcd existed as a directory in the package.

I installed it before 9.0.0. The directory was created by copying from the package. The permissions in the package were 0755, since it's the default `install`'s permissions.

In 9.0.0 the directory was no longer in the package, but tmpfiles.d updated the permissions to 0700 on the filesystem.

As such before installing 9.2.0 I had /var/lib/dhcpcd with 0700 on the filesystem, but the directory reappeared in the package with 0755.

Regarding which is better. If it works with 0700 (I haven't been using dhcpcd for a while now), then that is better. And that is what the patch supplied by loqs does.

It *is* working with 700 for me for a long time now, and there's nothing that 9.2.0 introduced that seems to require it to be 755, but I might be wrong.

If it works with 700 then perhaps upstream could be convinced to create it that way by default?

I don't know if it would work with that mask in *all* platforms dhcpcd runs, so I'd say 755 would be a sane default for them. Anyway, we can check, ofc.

I've made this commit to match the permission to what dhcpcd uses if the directory is missing at runtime:
https://roy.marples.name/cgit/dhcpcd.git/commit/?id=e523ba082b71b22ac03a736fd82f05810606fdca

https://roy.marples.name/cgit/dhcpcd.git/tree/src/dhcpcd.c#n2251

Hey Roy, thanks for that. You think we should remove our tmpfile on Arch and make new installations use this mask? I mean, dhcpcd already get it's own user and group on Arch, but that might not be the case everywhere, so I get why allowing the group read access.

DBDIR is supposed to be owned by root:root (or root:wheel) now.
Infact the dhcpcd user shouldn't own anything on the disk.

OK, so we need to get rid of the tmpfile.

Roy, I'm working on preparing the 9.3.0 package on Arch and I'm dropping the tmpfiles dir. But, on most people's installations, the /var/lib/dhcpcd dir will still be:
a) owned by dhcpcd
b) have 700 permission

Also, the dhcpcd user owns the /run/dhcpcd directory. You've mentioned that must not be the case anymore, and those directories should be owned by root. I can use a .install file that sets this permissions on the user's directories, matching things with what upstream delivers. What do you think?

Matching upstream is always a good idea :)
I would also change the home directory of dhcpcd to an empty directory - the unpriv user should not read anything in the chroot.

Hmm, changing the home of the existing user on users installations is trickier, but I think it also can be done. So, to sum up:

/run/dhcpcd should be owned by root. And what about permissions? 755?

/var/lib/dhcpcd should also be owned by root and with permission 755, as per upstream.

dhcpcd remains as a privsep user, with /var/empty as home folder.

> /run/dhcpcd should be owned by root. And what about permissions? 755?

Yes

/var/lib/dhcpcd should also be owned by root and with permission 755, as per upstream.

No, upstream is 750

> dhcpcd remains as a privsep user, with /var/empty as home folder.

Yes. /var/empty should be owned by root:root as 755

Right, I noticed after I typed that upstream is 750 (for /var/lib/dhcpcd). Also, since this is part of the installation now, it goes away from tmpfiles. but, the run dir isn't, so I'm still going to create it through tmpfiles. So:

root:root 750 /var/lib/dhcpcd
root:root 755 /run/dhcpcd
root:root 755 /var/empty (home dir of dhcpcd user)

/run/dhcpcd should be created by dhcpcd.

Currently /run/dhcpcd is being created by systemd through the usage of tmpfiles. Is there any issue in continuing to do so through systemd?

I have no idea as I don't use systemd.

No problem. I'll drop the tmpfile and do some testing here.

It merely means the directory will be created both immediately after the package is updated, and during the boot process, using the specified user and permissions.

A given program may or may not have the permissions necessary to create directories in /run, so it's often useful, and unlike /var such directories cannot be packaged in "make install" since /run is after all a tmpfs.

I doubt it makes a difference one way or another for a program that is already capable of creating the needed directory.

As an interesting aside, this isn't actually systemd specific, though systemd did create it -- it is intended to be an open standard for putting together systems, and indeed openrc (a systemd competitor) had implemented their own tmpfiles parser: https://github.com/OpenRC/opentmpfiles

Just a heads up that I released dhcpcd-9.3.1, so update to that as well please :)