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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)