Re: hardlinks to setuid binaries

[George Georgalis <george%galis.org@localhost>]

On Thu, Mar 31, 2022 at 10:09 AM Steffen Nurpmeso <steffen%sdaoden.eu@localhost> wrote:
>
> Michael Richardson wrote in
>  <19821.1648745882@localhost>:
>  |
>  |George Georgalis <george%galis.org@localhost> wrote:
>  |> However, an audit of package hardlink count, warning on check,
>  |> block on upgrade (without --force), to facilitate finding extra links,
>  |> seems like a low cost sanity check?
>  |
>  |It sure seems like it's the upgrade process that needs to care to remove
>  |"old" suid bits on old executables.  Or alternatively, overwrite them \
>  |without
>  |changing the inode.  It's a tussle as to which is better.
>
> Yes exactly.  Drop the stuff, then atomic rename.  What else
> can it be to not have problems after the atomic rename.

While reporting unexpected link count in package check
or upgrade is informative, altering the mode or data of
extra links may be a bit heavy handed. While the data
would be on the same filesystem, it was certainly not
part of the OS install and in cases with legitimate use
of hardlinks, altering the target would certainly not
be expected, and could cause problems at the site.

For example, imagine a scientific HPC site with the
requirement of being able to reproduce computational
runs. An administrator maintains the compute OS and
packages, Prior to a client data run, a novel prefix is
created for nfs export of hardlinked OS files and site
software. Then the job is executed and the prefix
is retained for runs with alternate parameters or
corrected data. Simultaneously, another prefix is
created for another project. In this scenario, multiple
scientific staff could easily be submitting multiple
jobs, while multiple prefixes are maintained by multiple
quality people. While this all progresses swimmingly
an administrator updates the reference OS and packages
only to find all the links in per client prefix have been
overwritten?

The administrator could copy the reference OS to an
alternate root vs the one being maintained, to prevent
linked binaries from being changed by OS upgrades,
but my position is sanitizing the files (links) outside of
the expected OS path is not expected behavior at all.

-George

-- 
George Georgalis, (415) 894-2710, http://www.galis.org/