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 different permissions. 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: release/picobsd/tinyware/passwd/Makefile sbin/shutdown/Makefile usr.bin/at/Makefile usr.sbin/authpf/Makefile 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.
LGTM now : manu@amy> pkg which /sbin/shutdown /sbin/shutdown was installed by package FreeBSD-runtime-14.snap20210408110717 manu@amy> ls -l /sbin/shutdown -r-sr-xr-- 2 root operator 15808 Apr 8 12:08 /sbin/shutdown