Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> writes:
> Hi again,
>
> On Sun, 13 Apr 2025 14:14:29 +0200
> Rutherther <ruthert...@ditigal.xyz> wrote:
>> Singularity patches the source to point to /run/privileged/bin, but as
>> I've said previously, I don't think that's a good way to go.
>> IMO it's much better to at least go with 1. check /run/privileged/bin,
>> 2. fallback to the gnu store output. Or posibly replacing 1 with
>> checking PATH.
> Maybe you had something somewhat similar in mind.
>
> After thinking about it, this could probably be done precisely by
> having some generic function that wraps the binary that needs to be
> privileged (like setuid-wrap or something like that) and that wrapper
> and the binary would be shipped as part of the package.
>
> The result would be something relatively easy to use for packager as we
> would just need to change the path to another path and not to have to
> code any logic inside the application itself (so people don't need to
> know every programming language out there).
>
> The wrapper should be relatively easy to write but I wonder if the
> string to change can be predicted in advance.
>
> For instance if we have a dependency we can refer to it as its path in
> /gnu/store is already known, but is it known before the compilation?
Of course it is, it is the package build script that puts it to the
output in install phase, so it's known.
>
> Can we patch source code to change a string to
> /gnu/store/<-hash>-wireshark-<version>/bin/dumpcap ?
>
> Denis.
Hi Denis,
this sounds good! No, it's not what I had in mind, I really didn't
consider anything with wrappers, the only reason I had something about
wrappers in my code was just to unwrap already wrapped binary, to
support setuid/capabilities.
We definitely can patch the code to do anything, but with what you
outlined I think we don't really have to do that at all. Now I see a way
I consider the best from the solutions outlined in this thread:
1. wireshark will point to what it pointed always... #$output/bin/dumpcap
2. This bin/dumpcap will not be the real dumpcap, but a wrapper
executable, not an interpreted, a compiled one. It must be one, because
we cannot use capabilities with interpreted executables.
The contents of this executable would be something like (probably in C,
but shell code is easier for me to write now)
```
if [[ -f /run/privileged/bin/dumpcap ]]; then
exec -a "$0" /run/privileged/bin/dumpcap "$@"
fi
exec -a "$0" #$output/bin/.privileged/dumpcap "$@"
```
3. The real dumpcap will be living at #$output/bin/.privileged/dumpcap
So there is no patching of the sources at all! The only change will be
adding a new phase, probably after gtk wrapping that will do those steps:
The state in this phase is: #$output/bin/dumpcap is wrapped binary,
adding gtk env vars and exec'ing #$output/bin/.dumpcap-real
So what we do:
1. Move #$output/bin/.dumpcap-real to #$output/bin/.privileged/dumpcap
2. Delete #$output/bin/dumpcap
3. compile a simple C file that will do what I outlined in shell script
earlier
4. put the output to #$output/bin/dumpcap
The reason for making a subfolder instead of naming the executable
something like .dumpcap-real is to make it easy to use in privileged
program service. It will use the name of the program executable, it
doesn't support changing it, so we would end up with
/run/privileged/bin/.dumpcap-real in that case, that doesn't look so good.
I am not sure what folder would be most appropriate, so I came up with
this '.privileged' under bin folder...
The result is, we have a working dumpcap on both Guix System and foreign
distros, with almost no maintainance burden, possibility to extend this
to any package, and ease of making a service for it! The service will
be extending profile service with wireshark, and privileged program
service with
```
(privileged-program
(program
(file-append wireshark "/bin/.privileged/dumpcap"))
(capabilities "cap_net_raw,cap_net_admin=eip"))
```
If this was to be made to a generic procedure, the step 1. would have to
be modified a bit, first of all it's possible the executable will not be
wrapped, and second, it's possible that it will be wrapped, but that we
want to keep the wrapping. I will have to investigate if capabilities
are dropped when interpreted executable is anywhere, or only if it's the
entrypoint. If only if it's the entrypoint, then everything is fine and
we can just keep the wrappers intact, just moving them to subfolder.
What do you think? Thanks for your input!
Best regards,
Rutherther
PS: I wouldn't worry about that GCD for getting rid of wrappers, none of
its arguments apply here. It solves a different issue.
