search

giuliano108 / guix-packages

Guix on WSL2, packages and notes
GNU General Public License v3.0
52 stars 9 forks source link

Properly handle setuid programs on WSL #13

Closed mapsmap55 closed 2 years ago

mapsmap55 commented 2 years ago

WSL mounts /run with the noexec and nosuid mount flags, preventing /run/setuid-programs from being executed setuid (in fact, they can't be executed whatsoever from that location).

The existing workaround to allow setuid usage of ping, su, and sudo is insufficiently general. I also suspect that it modifies the contents of packages within /gnu/store (a directory intended to be immutable except to the guix daemon).

As a replacement for the existing workaround, this change copies the setuid programs into a directory under /var/run and uses a bind mount to make /run/setuid-programs work as expected.

giuliano108 commented 2 years ago

Thanks @mapsmap55 for this, it makes perfect sense.

Btw, it doesn't look like files under /run/setuid-programs are links, neither soft nor hard (confirmed using stat). This might be the place where the plain file copy happens: https://github.com/guix-mirror/guix/blob/011dab59d80690d20875d43e73c3cfd8af95af99/gnu/build/activation.scm#L293 .

I'll merge your PR and also fix this (which is used by an automated distro creation script I've added recently).

Thanks again!

mapsmap55 commented 2 years ago

For the issue regarding setuid in /gnu/store, I was referring to this line in the original workaround:

chmod 4755 $(readlink -f $(which $f))

I don't have a system at hand to check, but as I recall, the invocation to which does not return the path under /run/setuid-programs (it skips over it since it's not executable, even though it exists with the executable bit in the filesystem). Rather, it returns a path under /run/current-system, which is a symbolic link into the store (after all, readlink would fail if it were a plain file).

giuliano108 commented 2 years ago

I just checked and you are 100% right. Thanks again!