Bug 234886 - shutdown not installed with setuid bit in pkgbase
Summary: shutdown not installed with setuid bit in pkgbase
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
Keywords: pkgbase
Depends on:
Reported: 2019-01-11 20:45 UTC by Ed Maste
Modified: 2020-01-22 17:53 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2019-01-11 20:45:40 UTC
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:


And after that email was sent, also stand/efi/loader/Makefile and stand/i386/loader/Makefile
Comment 1 Ed Maste freebsd_committer 2020-01-22 17:53:04 UTC
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.