[Solved] metapackage directory permissions differ

dtjohnst · 2020-02-26 02:11:00

I'm trying to learn how PKGBUILDs work so I've made my own and I can't seem to find where I set the permissions in my package. For example, in my PKGBUILD, in the package() function, I created a directory to store my files. I used:

install -dm 0700 "$pkgdir/etc/dtjohnst.d"
install -Dm 0600 "$srcdir/creds.conf" "$pkgdir/etc/dtjohnst.d"

That works fine and when I installed my package, my "creds.conf" file was correctly installed in /etc/dtjohnst.d. It has 600 permissions and the dtjohnst.d directory has 0700 permissions. But when I update my package, I get a warning

warning: directory permissions differ on /etc/dtjohnst.d
filesystem: 700  package: 755

I would have thought that by specifying the permissions when I create the directory in my PKGBUILD that they would be correct. Obviously that's not the case and I assume I'm doing it wrong. What is the proper way to create a directory and assign permissions in a PKGBUILD?

Thanks for your time!

Last edited by dtjohnst (2020-02-28 20:17:08)

eschwartz · 2020-02-26 03:19:44

I used the exact code you did and got different results: pacman did not complain.

$ cat PKGBUILD
pkgname=metapkg
pkgver=1
pkgrel=1
arch=('any')

prepare() {
    touch creds.conf
}

package() {
    install -dm 0700 "$pkgdir/etc/dtjohnst.d"
    install -Dm 0600 "$srcdir/creds.conf" "$pkgdir/etc/dtjohnst.d"
}

$ bsdtar -tvf metapkg-1-1-any.pkg.tar.zst 
-rw-r--r--  0 root   root    62463 Feb 25 22:15 .BUILDINFO
-rw-r--r--  0 root   root      366 Feb 25 22:15 .MTREE
-rw-r--r--  0 root   root      228 Feb 25 22:15 .PKGINFO
drwxr-xr-x  0 root   root        0 Feb 25 22:15 etc/
drwx------  0 root   root        0 Feb 25 22:15 etc/dtjohnst.d/
-rw-------  0 root   root        0 Feb 25 22:15 etc/dtjohnst.d/creds.conf

The resulting package definitely has the correct permissions as defined by install -dm700.

Are you *sure* the new package does not have 755 permissions? Can you post the PKGBUILD in question? What happens if you do `stat "$pkgdir/etc/dtjohnst.d"` at the end of package(), do you see any unexpected permissions being reported?

Last edited by eschwartz (2020-02-26 03:22:55)

dtjohnst · 2020-02-28 18:53:49

Sorry for the late reply, life got in the way.

You are absolutely correct in that it works properly, but that just exposed my understanding of the problem was wrong. I've investigated further and devised some samples to demonstrate the problem I'm having.

Essentially, one metapackage depends on another, and since the dependency creates the folder, I'm not including any code to recreate it in the subsequent package. The result is that the dependency has the correct permissions since they are explicitly stated, but packages which depend on it do not.

Here are two example packages:

# Maintainer: dtjohnst
pkgname=pkg1
pkgver=1
pkgrel=1
pkgdesc='First testing metapackage'
arch=('x86_64')
url='https://example.com'
license=('GPL')
package() {
    touch "$srcdir/file1.txt"
    install -dm 0700 "$pkgdir/etc/dtjohnst.d"
    install -Dm 0600 "$srcdir/file1.txt" "$pkgdir/etc/dtjohnst.d/file1.txt"
}

# Maintainer: dtjohnst
pkgname=pkg2
pkgver=1
pkgrel=1
pkgdesc='Second testing metapackage'
arch=('x86_64')
url='https://example.com'
license=('GPL')
depends=('pkg1')
package() {
    touch "$srcdir/file2.txt"
    install -Dm 0600 "$srcdir/file2.txt" "$pkgdir/etc/dtjohnst.d/file2.txt"
}

After building both,the permissions do indeed differ. With both package files in the same directory:

% for i in *.pkg.tar.zst; do; echo "$i $(bsdtar -tvf $i | grep -E etc/dtjohnst.d/$)"; done
pkg1-1-1-x86_64.pkg.tar.zst drwx------  0 root   root        0 Feb 28 13:32 etc/dtjohnst.d/
pkg2-1-1-x86_64.pkg.tar.zst drwxr-xr-x  0 root   root        0 Feb 28 13:49 etc/dtjohnst.d/

On updating the subsequent package, I get the error that permissions differ, which they do. I'd rather avoid defining the permissions of common folders in every package as it would mean duplication of work should anything change. Perhaps systemd-tmpfiles would be the correct way to do this? Is there a better method? Or am I stuck just having to declare it every time?

Last edited by dtjohnst (2020-02-28 18:54:45)

eschwartz · 2020-02-28 19:01:18

You need to declare it every time. Each package records the directory and file permissions of *all* its content, and directories can overlap in multiple packages (they must, so that /usr works ). If two packages have different permissions for a common directory, then the first one to be installed, "wins", and the other package will forever keep on printing that warning.

pacman cannot know which one is right, so it needs to be fixed in the PKGBUILD.

Why do both metapackages need to package this directory? Alternatively, is it reasonable to build both metapackages from one split-package PKGBUILD?

Would you find https://www.archlinux.org/pacman/makepk … ate.1.html helpful for updating multiple PKGBUILD files for common changes?

dtjohnst · 2020-02-28 20:16:52

Understood. I'll mark this as solved since the solution has been presented and do some research into how best to deal with this for my situation.

The reason for this is that my metapackages contain my own config files. I've seen a few solutions to deal with this but none seemed ideal to me. For example, if I wanted to have a custom sshd_config, I can't just install it via package() or I get an error about file conflicts. I could create a temporary file and just overwrite the original, but instead I've just chosen to have my own .d directory in /etc where I store all my custom config files. I can then chose to use them, or not, as the usage of the system dictates. For many I just also have some systemd drop-ins included with my metapackage that change the config file locations. I know there's a lot of ways to handle this but that has been working well for me aside from the differing permissions warnings, which are just warnings after all.

I know there are other options too, like ansible or etckeeper, and even other ways people have handled custom configs in metapackages like overwriting the original via an install file, so I may explore other ways to deal with it including digging deeper into the provided link.

Thanks.

eschwartz · 2020-02-28 20:29:50

No, no, no, packaging your configs via dropins is a very reasonable approach. It's also increasingly something that upstream software is tending to support.

For example, the very latest version of openssh which was just released, allows you to use the Include directive in sshd_config, which means you can store those conf files as a dropin now.

(BTW: having dropin support makes ansible *much* easier, compared to very weird fiddly role dependencies. We've been trying to ansible'ize the aur.archlinux.org website, but it needs custom sshd_config rules and we already have another role installing an sshd_config for general access.)

Last edited by eschwartz (2020-02-28 20:31:53)

dtjohnst · 2020-02-28 20:46:44

Not to hijack my own thread and redirect the topic, but is there a more reasonable place to store them vs my method of creating my own directory in /etc where I can keep them centralized then? Should I just put them in the directory that the config file they are replacing exists?

To use my sshd example I mentioned above, I have /etc/dtjohnst.d/sshd_dtjohnst.conf, and then my metapackage installs /etc/systemd/system/sshd.service.d/config.conf which contains:

[Service]
ExecStart=
ExecStart=/usr/bin/sshd -f /etc/dtjohnst.d/sshd_dtjohnst.conf

I like this method because it allows me to troubleshoot any problems by just going back to the default files if necessary without having to download the packages and extract them. I also like that I can locate all my customized configs in one place without hunting for them, but I'm certainly aware that I'm no expert and so best practices may have developed based on experience that differ from what I'm doing. I also prefer this to methods that have been championed in various blogs (for example: https://disconnected.systems/blog/archl … g-configs) because most of them involve having two copies of the same file.

Last edited by dtjohnst (2020-02-28 20:51:25)

eschwartz · 2020-02-28 20:57:13

Well, like I said:

Bugzilla – Bug 2468 | Option to include external files to sshd_config
Announce: OpenSSH 8.2 released

You add this to your global sshd_config:

Include /etc/ssh/sshd_config.d/*.conf

Then package whatever you need.

Last edited by eschwartz (2020-02-28 20:59:00)

dtjohnst · 2020-02-28 21:53:23

Oh, I misunderstood what you meant by drop-in file. Got it now. Thanks.

Arch Linux

#1 2020-02-26 02:11:00

[Solved] metapackage directory permissions differ

#2 2020-02-26 03:19:44

Re: [Solved] metapackage directory permissions differ

#3 2020-02-28 18:53:49

Re: [Solved] metapackage directory permissions differ

#4 2020-02-28 19:01:18

Re: [Solved] metapackage directory permissions differ

#5 2020-02-28 20:16:52

Re: [Solved] metapackage directory permissions differ

#6 2020-02-28 20:29:50

Re: [Solved] metapackage directory permissions differ

#7 2020-02-28 20:46:44

Re: [Solved] metapackage directory permissions differ

#8 2020-02-28 20:57:13

Re: [Solved] metapackage directory permissions differ

#9 2020-02-28 21:53:23

Re: [Solved] metapackage directory permissions differ

Board footer