Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

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
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Eli Schwartz (eschwartz)
Architecture All
Severity Medium
Priority Normal
Reported Version 5.1.0
Due in Version 5.1.1
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

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
Comment by Eli Schwartz (eschwartz) - Wednesday, 30 May 2018, 04:06 GMT
"It is not proper" -- it is "proper" to do whatever we feel is necessary. It's not unreasonable to think that you should be the owner of the $BUILDDIR. You don't need to be the owner of the directory above it though...

Why do we feel it is necessary? Good question: https://lists.archlinux.org/pipermail/pacman-dev/2017-December/022203.html
Comment by James (thx1138) - Wednesday, 30 May 2018, 09:11 GMT
BTW, I'm not suggesting that the script should not *attempt* to *correct* the $BUILDDIR permissions. If needed and possible, that is an automated convenience. Perhaps, even

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?
Comment by Eli Schwartz (eschwartz) - Wednesday, 30 May 2018, 13:29 GMT
Running sudo is unacceptable in this context.

...

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.

Loading...