Here's a sad story:
* 70971457 is merged into shadow, allowing newgidmap/newuidmap to be
installed with file caps rather than setuid.
* https://bugs.archlinux.org/task/63248 is filed to take advantage of
this.
* The arch maintainer of the 'shadow' package notices that this doesn't
work, and submits a pull request to fix this in shadow.
* edf7547ad5 is merged, fixing the post install hooks.
The problem here is that distros have been building shadow with PAM for
O(years), but the install hooks have silently failed due to the
combination of the directory mismatch (suidubins vs suidsbins) and later
success with setuid'ing newgidmap/newuidmap.
With the install hooks fixed, those of us (Arch[1] and Gentoo[2] so far)
who never built shadow explicitly with --enable-account-tools-setuid are
now getting setuid account tools, and don't have PAM configuration
suitable for use with setuid account management tools.
It's entirely unclear to me why you'd want this, but I assume there's
some reason out there for it existing. Regardless, setuid binaries are
dangerous and shouldn't be enabled by default without good reason.
[1] https://bugs.archlinux.org/task/64836
[2] https://bugs.gentoo.org/702252
suidubins should be suidusbins, since these binaries are installed
${prefix}/sbin. This historically hasn't broken the build because
chmod of newgidmap/newuidmap succeeds, causing make to think the command
succeeded. Configuring shadow with --with-fcaps removes these final two
entries and exposes the chmod failure to make.
Some distros don't care about the split between /bin, /sbin, /usr/bin,
and /usr/sbin, so let them easily stuff binaries wherever they want.
This also fixes a problem during installation where-in a loop of 'chmod
4755' calls will mostly fail. However, because the last two succeed
(newuidmap/newgidmap), make considers the command to be a success.
Somewhat not-amusingly, configuring shadow with --with-fcaps will cause
installation to fail because the final chmod call is now a failing one.
Dave Reisner