Arch Linux User Repository

@ettavolt: You're partially right :)

If the files were simply copied to chroot dir it will work as files can have executable bit (x) on noexec filesystem - it's just not effective.

The problem is that in Archlinux chroot they're bind mounted, see https://git.archlinux.org/devtools.git/tree/makechrootpkg.in#n419 . That means original mount point flags like noexec are inherited and the build will fail.

So in this example mounting /home (or /var or whatever) with noexec will even break building in clean chroot (assuming /home is where you downloaded PKGBUILD). That's why using ./some-script is harmful in PKGBUILD.

Even if the files are copied from noexec FS into clean chroot for that kind of build, they'll miss the flag, won't they?

@ettavolt: It's not about BUILDDIR (which is set to /tmp as default) directory where packages are being built. It's about SRCDEST (which defaults to dir where PKGBUILD is stored).

If you download brscan4 snapshot to /home mounted with noexec it will still break building in /tmp mounted with default flags. That's because files (like mk-udev-rules) from /home will be symlinked to /tmp. That's the essence of this issue.

Luckily this problem goes away with a trivial change :)

To quote the wiki:

the most restrictive … without losing functionality

Particularly, noexec on /tmp is said

breaks compiling packages and various other things

Also, many other packages execute some script as a part of build process. sane itself uses a built undistributed binary to write udev rules.

@Harey

Well, I did my best to explain the benefit. Mounting partitions with noexec flag is what Arch wiki recommends for security: https://wiki.archlinux.org/index.php/Security#Mount_options . I don't understand why not use my approach which will work always instead of something which can break in a known scenario. I'm modifying this locally for years but I thought it would be beneficial to upstream it to prevent everyone from hitting this issue.

@egrupled: I don't see the benefit for this but you are always free to edit the PKGBUILD to suit your needs before building. Anybody else having the same problem?

@Harey

Yes, it breaks when you try building the package and the directory where you downloaded sources is mounted with noexec flag.

In such case executing scripts directly like ./some-script will fail with permission denied.

But executing scripts by passing them to interpreter like bash some-script, python some-script or gawk -f some-script will still work.

The script functionality is unchanged so there is no downside of doing this change.

@egrupled: Could you describe the scenario a bit more and why somebody wants to use it? It breaks only while building the package, right?

Hi, thx for providing this package!

Could you change in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brscan4#n26

./mk-udev-rules opt/brother/scanner/brscan4/{Brsane4.ini,models4/*.ini} > etc/udev/rules.d/40-$pkgname.rules

to:

gawk -f mk-udev-rules opt/brother/scanner/brscan4/{Brsane4.ini,models4/*.ini} > etc/udev/rules.d/40-$pkgname.rules

Otherwise it breaks when "mk-udev-rules" is cached on mount point with "noexec" flag.

updated to 0.4.5_1 @ron2138 I changed the upstream URL to something more unspecified because the one you provided did not have the latest updates. Thanks for reporting upstreams - please keep us informed if you get an answer.