Arch Linux

"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

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?

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.