Re: chmod failing with EPERM and PRIV_ALL needed

[Jim Meyering]

David Bartley wrote:
> I've encountered a bug in tar on OpenSolaris (possibly present in
> Solaris 10 and others). I have a tarball that contains a setuid binary
> (usr/bin/passwd). When I untar it as root, I see the following error:
>
> tar: usr/bin/passwd: Cannot change mode to r-sr-sr-x: Not owner
>
> Running this under truss we see:
>
> 2655: getppriv(PRIV_EFFECTIVE, {ffffffffffffffffffffffff}) = 0
> 2655:     all
> 2655: setppriv(PRIV_SET, PRIV_EFFECTIVE, {ffffffffffffbfffffffffff}) = 0
> 2655:     all,!sys_linkdir
> 2655: unlink("usr/bin/passwd") = 0
> 2655: open64("usr/bin/passwd", O_WRONLY|O_CREAT|O_EXCL, 0500) = 4
> .
> .
> .
> 2655: chown("usr/bin/passwd", 0, 3) = 0
> 2655: chmod("usr/bin/passwd", 06555) Err#1 EPERM [ALL]
>
> The priv calls occur in the cannot_unlink_dir function of gnulib and
> disable the ability of unlink to remove a directory; the
> PRIV_SYS_LINKDIR privilege is removed from the effective set. The
> [ALL] part of the failed chmod means that we need PRIV_ALL (i.e. all
> privileges) for this to work. Since we removed a privilege, we don't
> have PRIV_ALL. I couldn't find any Solaris docs explaining why
> PRIV_ALL is required so I've asked on the opensolaris mailing list for
> some details [1]. Offhand, I would guess this is a security measure of
> setuid root binaries.
>
> [1] http://opensolaris.org/jive/thread.jspa?threadID=95826

Thanks for the report.  I read Casper's reply.

That function removes PRIV_SYS_LINKDIR for the sake of security.
Without it, there's a guaranteed race condition that may lead to
unlinking a non-empty directory.

It's ironic that Solaris' privilege system does not accommodate that.
But if you explain to them why we're doing it, maybe they'll
recognize the utility of it and relax the model.