As reported by kmoore in https://lists.freebsd.org/pipermail/freebsd-pkgbase/2017-December/000350.html:
> Anybody else noticed a recent regression (say past month or so) where
> pkg base of latest HEAD is now failing to throw setuid on some files? We
> saw it at first because /sbin/shutdown lost its setuid bit, so users
> can't shutdown the box.
I investigated and found that it appears to be due to the way install(1) handles links with -M (https://lists.freebsd.org/pipermail/freebsd-pkgbase/2017-December/000361.html):
For regular installs we invoke:
install -l h <prog> <link>
and the link then has the same permissions via the existing inode.
With -M install produces a metalog containing
./<link> type=file mode=0755 size=0
(i.e., permissions not explicitly set) and we end up with two entries
in the metalog referencing two names for the same inode, but with
If we passed in the mode when invoking install for a hardlink we
should have the expected permissions, regardless of sorting:
# install -M METALOG -m4554 -l h <prog> <link>
./<link> type=file mode=04554 size=0
On a positive note there are only a few Makefiles with LINKS as well
as BINOWN, BINMODE, or BINGRP. As far as I can tell:
And after that email was sent, also stand/efi/loader/Makefile and stand/i386/loader/Makefile
Note that as of r335797 (https://reviews.freebsd.org/rS335797) we do pass the user/group/perms to install when creating the link, but tools/install.sh ignores the information.