access control

[jon1enforce]

ok, files must include in /home/xsunaba ; such as download files or other workflows.
But this should also work with multiple users? do it? Just change the namespace?
Pretty nice. But drivers do not load..
need access to X11/lib/modules/dri... denied.
or figure out the default file(access) with trace such as fatrace[https://github.com/martinpitt/fatrace], or python import trace..as simple script.(feature)

[morgant]

@jon1enforce Thanks for the feedback regarding areas for improvement in the README!

You are correct that, by default, Xsunaba runs as the xsunaba user, so it will only have access to /home/xsunaba. If you want to share permissions with another user, which should be done with great caution as Xsunaba is intended to be used to greatly restrict access to files, I'd suggest creating a directory which is owned by the xsunaba user and has read/write permission for your own user's group (generally the same as your username).

As for access to X11/lib/modules/dri, I have not personally run into that when using Xsunaba under OpenBSD with xenodm. What OS, display manager, and window manager (or desktop environment) are you currently running.

In the case of OpenBSD, the xenodm display manager (a more secure descendent of xdm) handles the login window and has some scripts which take/give ownership of dri and such upon X11 user session login/logout. Since Xsunaba handles the shared X11 authentication/authorization between your user and the xsunaba user, it should just work, but using startx under OpenBSD or a different display manager and OS might still require additional permissions handling.

[morgant]

@jon1enforce I have updated the README to clarify what is sandboxed and how (integrating some points from our discussion in Issue #1), plus notes on permissions & sharing files with the sandbox user.

Is there anything else you feel it would be important for me to include?

[morgant]

I thought I had noted this much earlier, but there wasn't anything in the README nor any of the issues/comments here, so I've now updated the README regarding Xephyr only providing a software rasterizer for OpenGL via the llvmpipe driver, not any hardware acceleration. See my latest commit.

Related to that, while I mentioned xenodm handles changing dri driver permissions on login/logout, Xephyr doesn't use a display manager (e.g. xenodm) or window manager... now also noted in the README. This means that the sandbox doesn't change dri device permissions, which would screw up the primary X session which is already using the dri devices anyway. It also means that the sandbox user's ~/.xsession (xenodm) or ~/.xinirc (startx) are not executed since it's not really performing a full "login".