| 30 Nov 2025 |
 raitobezarius | In reply to @jlamur:matrix.org
yep you're right, running with eg podman run --cap-add=SYS_ADMIN --security-opt unmask=/proc/* --rm -it works I think you can get remove just the unshare blacklist | 21:40:13 |
| raitobezarius | Don't need to unmask proc and cap add | 21:40:20 |
| raitobezarius | For proc, you only need a partial view, not a full view anyway, but you need a proper procfs I suppose | 21:41:03 |
 Jules Lamur | AFAIU, podman sets a policy that prevents any mount related syscall in /proc, so remounting a procfs should not work at all without the --security-opt flag above (again, if I understand correctly -- I only have a high level understanding of all that) | 21:43:18 |
| raitobezarius | Argh, yeah, we need *a* procfs | 21:44:11 |
| raitobezarius | Not necessarily *the* procfs | 21:44:16 |
| Jules Lamur | I'm not sure that I understand what you're suggesting here | 21:44:51 |
| raitobezarius | In reply to @jlamur:matrix.org
I'm not sure that I understand what you're suggesting here --security-opt seccomp reduced-seccomp.json | 21:45:29 |
| raitobezarius | The JSON file is a fine grained control of which syscall is allowed | 21:46:23 |
| raitobezarius | Allowing unshare makes sense if you want the sandbox to work at all | 21:46:45 |
| raitobezarius | Perhaps, allowing the mount procfs is sufficiently risk free too | 21:46:56 |
| Jules Lamur | what do you mean by allowing unshare? user namespaces are allowed by default in podman rootless containers so unshare should work out of the box | 21:48:43 |
| raitobezarius | I was pretty sure the default seccomp policy forbids the unshare syscall | 21:49:08 |
| Jules Lamur | (that does not solve my problem though because of the procfs mask) | 21:49:13 |
| raitobezarius | So maybe the question is: if you try to allow the mount syscall for procfs, does it work? | 21:49:35 |
| raitobezarius | Without any cap or proc unmasking | 21:49:41 |
| Jules Lamur | If I try to run with only the unmask, then I get that:
$ podman run --security-opt unmask=/proc/* --rm -it foo unshare -r nix-build
error: changing ownership of path '/nix/store': Invalid argument
| 21:52:54 |
| Jules Lamur | mhh I think that's because /nix/store is root:nogroup in the new user ns | 21:55:10 |
| raitobezarius | That's very weird to have EINVAL on chown? Do you have a clean mount namespace? | 21:55:12 |
| raitobezarius | In reply to @jlamur:matrix.org
mhh I think that's because /nix/store is root:nogroup in the new user ns So subuid delegation | 21:55:24 |
 WeetHet | WYM? | 21:56:57 |
| raitobezarius | In reply to @weethet:catgirl.cloud
WYM? The surface of API calls used for nix-doc is extremely low and trivial | 21:57:48 |
| raitobezarius | It's absolutely not representative of general purpose FFI for CLI alas | 21:58:05 |
| WeetHet | Autocxx doesn't support exceptions 😞 | 21:59:46 |
| WeetHet | * Autocxx doesn't support exceptions | 21:59:53 |
| WeetHet | But there's a PR: https://github.com/google/autocxx/pull/1426 | 22:00:05 |
| raitobezarius | Seems too old :p | 22:31:42 |
| raitobezarius | Even if C++ exceptions were tackled, not sure how to interpp C++ coroutines and Rust async coroutine transformations | 22:32:39 |
|  @anouk:kif.rocks left the room. | 23:28:51 |
 niko ⚡️ | and this is even more unexpected: nix-building a file like this { __functor = self: <derivation>; }, which obviously isn't "valid" nix code (technically valid, but for the sake of brevity let's just say it's invalid), actually builds the derivation... what? Surely this is not expected, that's not how functors work | 23:51:11 |
