Proper way to do setcap in maintscript

[Niels Thykier]

Hi,

I have seen the following pattern in multiple packages, where we use
`setcap` to replace a setuid (or setgid) mode with a capability. I think
it is about time that we get proper packaging helper support for it.


```
if [ "$1" = configure ]; then
if command -v setcap > /dev/null; then
if setcap CAP CMD then
chmod u-s CMD
else
echo "Setcap failed ..." >&2
fi
else
echo "Setcap is not installed, ..." >&2
fi
fi
```

If I was to add support for this snippet in package helpers, is there
anything I should change in it? Such as:

* Should the snippet use dpkg-statoverride instead of a chmod?
(If dpkg-statoverride is used, how will this interact with the next
bullet?)
* Should the snippet use $DPKG_ROOT for the CMD even though setcap
would presumably have to be run from the HOST system?

The snippet format has been used for a while, so it definitely "works".
But I figured the basic template could do with a review to see if it is
still up to speed with best practices - especially if we start adding it
to a package helper. :)

Best regards,
Niels

PS: I am also happy to receive suggestions for how to integrate this
better with dpkg. My understanding though is that it will come with the
dpkg manifest format, so I assumed the package helper just had to do
some maintscript glue for now.

[Helmut Grohne]

Hi Niels,

thanks for reaching out.

On Sat, Nov 18, 2023 at 05:13:44PM +0100, Niels Thykier wrote:
> * Should the snippet use dpkg-statoverride instead of a chmod?
> (If dpkg-statoverride is used, how will this interact with the next
> bullet?)

I don't think dpkg-statoverride can do capabilities so we couldn't track
that anyway. Also note that dpkg-statoverride needs a bit of attention
when it comes to /usr-merge (DEP17 P5) while the snippet will probably
just work.

> * Should the snippet use $DPKG_ROOT for the CMD even though setcap
> would presumably have to be run from the HOST system?

The commands should be used from the build system (i.e. without
DPKG_ROOT). We expect that if DPKG_ROOT is being used, it is being used
for all operations on the chroot and that packages are never upgraded
(i.e. we're always in a kind of bootstrap setting).

On the flip side, the paths to be operated on would benefit from being
prefixed by DPKG_ROOT.

> PS: I am also happy to receive suggestions for how to integrate this better
> with dpkg. My understanding though is that it will come with the dpkg
> manifest format, so I assumed the package helper just had to do some
> maintscript glue for now.

I also hope that we have more fundamental dpkg support for this before
too long.

Helmut

[Niels Thykier]

Helmut Grohne:

> Hi Niels,
>
> thanks for reaching out.
>

Thanks for the quick feedback. :)

> On Sat, Nov 18, 2023 at 05:13:44PM +0100, Niels Thykier wrote:
>> * Should the snippet use dpkg-statoverride instead of a chmod?
>> (If dpkg-statoverride is used, how will this interact with the next
>> bullet?)
>
> I don't think dpkg-statoverride can do capabilities so we couldn't track
> that anyway.

As a clarification, I meant using dpkg-statoverride for the `chmod u-s`
part, so the dpkg is aware that the mode change is deliberate.

> Also note that dpkg-statoverride needs a bit of attention
> when it comes to /usr-merge (DEP17 P5) while the snippet will probably
> just work.
>
>> * Should the snippet use $DPKG_ROOT for the CMD even though setcap
>> would presumably have to be run from the HOST system?
>
> The commands should be used from the build system (i.e. without
> DPKG_ROOT). We expect that if DPKG_ROOT is being used, it is being used
> for all operations on the chroot and that packages are never upgraded
> (i.e. we're always in a kind of bootstrap setting).
>
> On the flip side, the paths to be operated on would benefit from being
> prefixed by DPKG_ROOT.
>

Ok. Just confirm, are we then looking at something like:

```
if [ "$1" = configure ]; then
if command -v setcap > /dev/null; then

if setcap CAP ${DPKG_ROOT}CMD then
chmod u-s ${DPKG_ROOT}CMD

else
echo "Setcap failed ..." >&2
fi
else
echo "Setcap is not installed, ..." >&2
fi
fi
```

>> PS: I am also happy to receive suggestions for how to integrate this better
>> with dpkg. My understanding though is that it will come with the dpkg
>> manifest format, so I assumed the package helper just had to do some
>> maintscript glue for now.
>
> I also hope that we have more fundamental dpkg support for this before
> too long.
>
> Helmut
>

:)

Thanks,
~Niels

[Niels Thykier]

Niels Thykier:

> Hi,
>
> I have seen the following pattern in multiple packages, where we use
> `setcap` to replace a setuid (or setgid) mode with a capability. I think
> it is about time that we get proper packaging helper support for it.
>

> [...]
>
> Best regards,
> Niels
>
> [...]
>

Hi

Thanks for the feedback so far. :)

I have ended up with the snippet below, which includes:

1) Use of `dpkg-divert --truename` to make the code work the same even
if the command has been diverted (seen in iputils-ping's setcap
script).
2) Use of `${DPKG_ROOT}` as suggested by Helmut.

> # Snippet source: debputy (translate-capabilities)
> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ]; then

> if command -v setcap > /dev/null; then

> # Triggered by: packages.dh-debputy.transformations[0].path-metadata <Search for: /usr/bin/dh_debputy>
> _TPATH=$(dpkg-divert --truename /usr/bin/dh_debputy)
> if setcap cap_net_raw+ep "${DPKG_ROOT}${_TPATH}"; then
> chmod a-s "${DPKG_ROOT}${_TPATH}"
> echo "Successfully applied capabilities cap_net_raw+ep on ${_TPATH}"
> else
> echo "The setcap failed to processes cap_net_raw+ep on ${_TPATH}; falling back to no capability support" >&2
> fi
> unset _TPATH
> else
> echo "The setcap utility is not installed available; falling back to no capability support" >&2
> fi
> fi


The use of `/usr/bin/dh_debputy` and related capability was just a value
for the sake of testing the code.

Best regards,
Niels