FS#58790 - [makepkg] chmod: changing permissions of '/var/build/': Operation not permitted
Attached to Project:
Pacman
Opened by James (thx1138) - Wednesday, 30 May 2018, 02:43 GMT
Last edited by Allan McRae (Allan) - Tuesday, 19 June 2018, 10:34 GMT
Opened by James (thx1138) - Wednesday, 30 May 2018, 02:43 GMT
Last edited by Allan McRae (Allan) - Tuesday, 19 June 2018, 10:34 GMT
|
Details
pacman 5.1.0-1
$ makepkg -csi chmod: changing permissions of '/var/build': Operation not permitted ==> ERROR: An unknown error has occurred. Exiting... ==> ERROR: An unknown error has occurred. Exiting... User defined signal 1 ---- /usr/bin/makepkg ... # check that all settings directories are user-writable if ! ensure_writable_dir "BUILDDIR" "$BUILDDIR"; then plain "$(gettext "Aborting...")" exit $E_FS_PERMISSIONS fi chmod a-s "$BUILDDIR" ... ---- It's one thing to make $BUILDDIR and subdirectories of $BUILDDIR user-writable, and it is a different thing to make the directory above $BUILDDIR user-writable. This is not the droid for which you are looking. "makepkg" does not run as root. It is proper to *check* that the permissions are not incorrect, but it is not proper to *change* the permissions. |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 19 June 2018, 10:34 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 737596f0
Tuesday, 19 June 2018, 10:34 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 737596f0
Why do we feel it is necessary? Good question: https://lists.archlinux.org/pipermail/pacman-dev/2017-December/022203.html
sudo chmod a-s "$BUILDDIR"
would be acceptable in makepkg, as a convenience, when attempting to unset the permission bits.
Rather, if the existing permissions are already correct, then the script should not abort for no reason.
And, the last of four possible circumstances, if the permissions are *not* already correct, and the script does *not* have write permissions on the
parent directory, *then*, and only then, yes, the script should abort with an error message clearly explaining that the $BUILDDIR directory has improper permissions and that the permissions must be set manually by the administrator of that parent directory.
Now, I'm a little confused about what is needed, from reading at https://lists.archlinux.org/pipermail/pacman-dev/2017-December/022203.html
---
> - chmod a-s "$BUILDDIR"
As discussed on IRC, this chmod is important. If the build dir gets
created with a sticky bit, that propagates through the package.
---
"chmod a-s <dir>" does *not* remove the "sticky bit", which is "t", not "s".
$ chmod 07640 test;sudo ls -al test
total 8
drwSr-S--T 2 james james 4096 May 30 04:43 .
drwxr-x--- 4 james james 4096 May 30 04:43 ..
$ chmod a-s test;sudo ls -al test
total 8
drw-r----T 2 james james 4096 May 30 04:43 .
drwxr-x--- 4 james james 4096 May 30 04:43 ..
and
$ chmod 07640 test;sudo ls -al test
total 8
drwSr-S--T 2 james james 4096 May 30 04:43 .
drwxr-x--- 4 james james 4096 May 30 04:43 ..
$ chmod o-t test;sudo ls -al test
total 8
drwSr-S--- 2 james james 4096 May 30 04:43 .
drwxr-x--- 4 james james 4096 May 30 04:43 ..
What is actually meant here? Is it the "sticky bit" or the "restricted deletion flag" that is actually a problem?
From "man 1 chmod":
"The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit."
My impression has been that the effect of these flags can be file system dependent. Or, is that not true?
Regardless, I expect that the intent was to remove *all* of these special flags from the directory permissions, which would require
chmod a-s,o-t "$BUILDDIR"
So, functionally:
find "$BUILDDIR" -maxdepth 0 -perm /7000 -exec sh -c 'sudo chmod a-s,o-t {} \; || echo special directory flags error message'
Is there an easier way to test the permission bits on a directory?
...
allan, checking my logs:
2017-12-07 12:17:34 AM allanbrokeit you remove chmod a-s "$BUILDDIR"
2017-12-07 12:17:38 AM allanbrokeit This is an important chmod. From memory, any sticky bit gets inherited through the package without it.
2017-12-07 12:17:53 AM guys I see
2017-12-07 12:53:17 AM guys allanbrokeit: I'm thinking just unconditionally do chmod a-s, it's not like it hurts to do it when the dir already exi
sts
2017-12-07 12:55:25 AM allanbrokeit makepkg should not change permissions for existing directories. I would not count that as expected behaviour
2017-12-07 12:59:34 AM guys so it should cause the package to inherit the sticky bit if the dir already existed?
2017-12-07 01:01:09 AM allanbrokeit I need to look up the discussion from when that change was made to confirm what the issue was
2017-12-07 01:31:04 AM allanbrokeit guys: not sure we need the chmod a-s anywhere. It gets done on $srcdir and $pkgdir anyway
2017-12-07 01:31:53 AM guys hmm, that may be why I initially removed it, if it comes to that
2017-12-07 01:33:19 AM guys yeah, that a-s is done with a lot more granularity later on
2017-12-07 01:33:40 AM allanbrokeit I will go back to your original patch.... :D
I think we ended up using the wrong patch. It may not be strictly "wrong" to expect the $BUILDDIR to be owned by the build user, but it's unnecessary to use this chmod anyway.