IRC channel logs
2024-10-18.log
back to list of logs
<yvs>gdb gave some more info: wayland crashed at adding screen <yvs>#6 InitOutput (screen_info=screen_info@entry=0x636800 <screenInfo>, argc=argc@entry=17, argv=argv@entry=0x7fff8bca2f88) at ../xwayland-23.2.5/hw/xwayland/xwayland.c:435 <yvs>#5 FatalError (f=f@entry=0x58fb87 "Couldn't add screen\n") at ../xwayland-23.2.5/os/log.c:1017 <amano>I want guix shell --container to let me keep supplementary groups, pick a network namespace, filter dbus with xdg-dbus-proxy, and write application profiles. <amano>xdg-dbus-proxy can probably run as a shepherd service in `guix develop` which is being developed? <amano>Without granular control points, guix shell --container isn't useful for application sandboxing. <amano>Right now, I may just run firejail outside guix shell --container. <mange>Reading the manual, I feel like "guix shell" isn't intended to be a general purpose mechanism for sandboxing. It's a way to construct a temporary "software environment" (read: profile), and --container is a convenience for getting some sorts of programs working (e.g. with --emulate-fhs or --link-profile). <mange>I'd be wary of adding too many options taking it in the direction of sandboxing. That seems like a different concern, which may be solved better with another tool (I'm not familiar with firejail, but plausibly that?). <amano>guix shell --container only leaves you with necessary folders in /gnu/store. Firejail can't do that. <amano>I wish guix shell just restricts /gnu/store and leaves the rest to firejail. <amano>guix requires its own sandboxing soution. <amano>guix requires its own sandboxing solution. <amano>I want guix to have its own sandboxing solution that can substitute for firejail and apparmor. <amano>I don't let a web browser run artibrary code outside an application sandbox. <amano>I don't let a web browser run arbitrary code outside an application sandbox. <amano>Perhaps, somebody can write a guix software that creates apparmor profiles for guix. <amano>or a guix software can write firejail profiles for other guix softwares. <amano>However, it would be better for guix to have its own solution that's independent from apparmor and firejail. <amano>Guix is just too unique for apparmor and firejail. <amano>mange: --container drops supplementary groups which are required to make some things work. <mange>Okay. I don't know anything about firejail, but based on a quick read I imagine it would be possible to write a firejail profile that would expose everything you need (e.g. exposing only necessary parts of /gnu/store). <amano>Firejail doesn't understand /gnu/store. <amano>A guix software would have to write a firejail profile... <amano>Guix understands /gnu/store. <amano>That means a firejail profile for a guix package would be yet another guix package...? <mange>Firejail understands lists of things to expose in the jail. You could write a firejail profile for the specific software you want to run. <amano>I cannot know the paths to /gnu/store directories in advance. That has to come from guix itself. <amano>A guix package for a firejail profile should be written for another guix package. <amano>That means firejail profiles and apparmor profile have to come from guix packages.... <mange>Once you know what you want to run, you can get the paths. "guix build $package" will get you the path for the package, then "guix gc --references" can get you the rest (from memory... I might be wrong about which gc flag to use). <mange>Sure, I'm saying "write a firejail profile for the specific software you want to run". <amano>So, I have to change firejail profiles whenever the paths in /gnu/store change? <amano>I don't want to manually write paths. <mange>I have no idea how firejail works. <amano>I would have to manually write `whitelist /gnu/store/xxxxxx-firefox-11.2` in a firejail profile if I write firejail profiles by hand. <amano>That path will change over time. <mange>You could write a script to call Guix to get the relevant paths, and then call firejail with the right file/arguments. <amano>It's better for a guix package to dynamically generate a firejail profile.... <amano>mange: That is going to be slower than a pre-rendered firejail profile installed from a guix package. <amano>That said, guix shell --container should have an option to keep supplementary groups which are sometimes required. <mange>The code for that is the function launch-environment/container in guix/scripts/environment.scm if you want to give it a shot. <amano>I don't know how to write guile scheme. I don't really know the details of gnu guix. I just know surface concepts. <amano>I'm only good at playing with concepts. <amano>I already submitted an email about making guix shell --container keep supplementary groups to guix-dev mailing list. <amano>With firejail and apparmor, I get application sandboxing. <mange>Just to make sure I understand the situation: you can do what you want with firejail/apparmor, except for exposing directories in /gnu/store. I suggested a way to get the list of /gnu/store things to expose (which might be wrong - I haven't tried anything), and your response was "that will be slower". <mange>It sounds, to me, like you have a choice of tradeoff: you can spend time learning Guile, or you can run something slower (which you can likely cache). <mange>Or you can wait for someone else to implement your feature request, when they have the time and inclination.