[aur-general] Issue a warning while (re)packaging a binary package?
Hi, a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run. So I'd thought about adding a warning to the PKGBUILD if /tmp is mounted noexec (as on all of my maschines). Unfortunately I could not find a hint in the documentation if 1. this idea is considered "good behaviour" 2. where exactly to put the warning. My first attempt whould be something like adding a pre/post install check, if the directory is executable and print a message in case it is not. Any thoughts on this one? Thanks and best regards -- MfG Jan
On June 18, 2021 9:05:31 AM EDT, Jan Kohnert via aur-general
Hi,
a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run.
So I'd thought about adding a warning to the PKGBUILD if /tmp is mounted noexec (as on all of my maschines). Unfortunately I could not find a hint in the documentation if
1. this idea is considered "good behaviour" 2. where exactly to put the warning.
My first attempt whould be something like adding a pre/post install check, if the directory is executable and print a message in case it is not.
Any thoughts on this one?
Thanks and best regards
Try and see if it works 🤷. A message in post-install and post-upgrade should be sufficient. -- Best, Daniel https://danielcapella.com
On 18/06/2021 14:05, Jan Kohnert via aur-general wrote:
Hi,
a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run.
My immediate questions would be why, and is this an upstream issue? Or, is an executable /tmp a reasonable assumption? 🤔 J
On 18/06/2021 16:43, Jonathon Fernyhough via aur-general wrote:
On 18/06/2021 14:05, Jan Kohnert via aur-general wrote:
Hi,
a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run.
My immediate questions would be why, and is this an upstream issue?
Or, is an executable /tmp a reasonable assumption? 🤔
I don't see anything in file-hierarchy(7) that mandates an executable /tmp. That said, it contains a hint that some programs might break:       /tmp/, /var/tmp/ and /dev/shm/ should be mounted nosuid and       nodev, which means that set-user-id mode and character or block       special devices are not interpreted on those file systems. In       general it is not possible to mount them noexec, because various       programs use those directories for dynamically generated or       optimized code, and with that flag those use cases would break.       Using this flag is OK on special-purpose installations or systems       where all software that may be installed is known and doesn't       require such functionality. See the discussion of       nosuid/nodev/noexec in mount(8) and PROT_EXEC in mmap(2). Alad
J
On 18/06/2021 16:21, alad via aur-general wrote:
On 18/06/2021 16:43, Jonathon Fernyhough via aur-general wrote:
... Or, is an executable /tmp a reasonable assumption? 🤔
I don't see anything in file-hierarchy(7) that mandates an executable /tmp. That said, it contains a hint that some programs might break:
      /tmp/, /var/tmp/ and /dev/shm/ should be mounted nosuid and       nodev, which means that set-user-id mode and character or block       special devices are not interpreted on those file systems. In       general it is not possible to mount them noexec, because various       programs use those directories for dynamically generated or       optimized code, and with that flag those use cases would break.       Using this flag is OK on special-purpose installations or systems       where all software that may be installed is known and doesn't       require such functionality. See the discussion of       nosuid/nodev/noexec in mount(8) and PROT_EXEC in mmap(2).
This kind of implies that noexec would be a "special-purpose" case rather than the norm (as it's definitely not the default), which also implies it's a user-configuration issue rather than a packaging issue. Therefore, and thinking about saving Jan some work, is adding a warning necessary? (e.g. is there other software in the repos that would break with a noexec [/tmp,/var/tmp,/dev/shm], and if so, do any of those contain a warning about a non-default state?)
Hi, Am Freitag, 18. Juni 2021, 17:21:43 CEST schrieb alad via aur-general:
On 18/06/2021 16:43, Jonathon Fernyhough via aur-general wrote:
On 18/06/2021 14:05, Jan Kohnert via aur-general wrote:
a new version of a (binary) package I'm maintaining (clockify-desktop) requires an executable /tmp directory to run.
My immediate questions would be why, and is this an upstream issue?
I really don't know. Upstream changed their version 2.0.2 by a new upload They use S3 storage and have a unique filename for all versions; so I only figure out changes by automatic nightly builds on my GitlLab that fails when the hash changes. I contacted them and the answer I got was "the dev team works on a new version". They promised to notify me when a new version is available, but I can't tell when this will by the case.
Or, is an executable /tmp a reasonable assumption? 🤔
I don't see anything in file-hierarchy(7) that mandates an executable /tmp. That said, it contains a hint that some programs might break:
/tmp/, /var/tmp/ and /dev/shm/ should be mounted nosuid and nodev, which means that set-user-id mode and character or block special devices are not interpreted on those file systems. In general it is not possible to mount them noexec, because various programs use those directories for dynamically generated or optimized code, and with that flag those use cases would break. Using this flag is OK on special-purpose installations or systems where all software that may be installed is known and doesn't require such functionality. See the discussion of nosuid/nodev/noexec in mount(8) and PROT_EXEC in mmap(2).
Based on this, my setup seems a bit outdated. AFAIR the info to use noexec on / tmp is from the time I switched to Gentoo at around 2004 to remove a possible attack vector. There were even advices to mount /home and /var/tmp noexec to prevent users from executing arbitary code, as then all user-writeable directories whould be noexec. I never changed that setup at least for /tmp and /var/tmp for newer machines, but I do get some errors for some python-related packages from the AUR that require an executable /tmp for building. So maybe I'll just change my setup and push the new version without adding a warning. Thanks for clearification. :) -- MfG Jan
participants (4)
-
alad
-
Daniel M. Capella
-
Jan Kohnert
-
Jonathon Fernyhough