Otherwise please provide the manual command that works how to invoke bwrap as a script comment or here so I can have a look. If brwap manual invocation works (which must work) then I am pretty sure it can be scripted without bash -c.
Some apps (such as ristretto) are dying due to a lack of D-Bus and many more (such as hexchat) are giving off errors. I think we need to figure out how to start a D-Bus session bus for the sandbox users. Maybe via some systemd stuff. I couldn’t figure out how.
/shared is not a good folder location as this breaks FHS. Thereby the package gets unfit for inclusion in most distributions. It’s a new folder that is easily forgotten during backups.
Optimize for usability? Not necessarily an optimization problem.
Reading FHS again chapter /home. Relevant quotes…
/home is a fairly standard concept, but it is clearly a site-specific filesystem. [6]
[6] Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for user home directories.
On smaller systems, each user’s home directory is typically implemented as a subdirectory directly under /home , for example /home/smith , /home/torvalds , /home/operator , etc.
On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff , /home/guests , /home/students , etc.
I guess the sandbox use case is closest to “large systems” use case.
/home/sandbox seems appropriate.
/home/sandbox/sandbox-${app_name}
(Maybe sandbox- is superfluous. [1])
Therefore advise can stay “backup your home folder”. Meaning not /home/user but meaning backup /home.
That seems to be close to FHS and also be good for usability. Better than /var/lib/sandbox which is a lot harder to remember and backup. Contents of /home are more easily discovered than /var/lib.
Also /home/sandbox/shared or something would be good. But then we must make sure that no app can be named “shared”. [1]
Thinking for restricting user user, could a compromised user user mess with app_name and make an app that shouldn’t access another apps data?
/home/sandbox is too generic so I went with /home/sandbox-app-launcher-appdata. Messing with /home/sandbox-app-launcher-appdata/shared isn’t very usable. /shared is far shorter to type and easier to remember. Shared storage is something that users will likely use often (unlike the autogenerated/home directories) so it needs to be more usable.
I don’t really see much issue with /shared. We don’t need to go all out following FHS. Even popular software like Flatpak has /app.
No. I don’t see how they could do that. app_name is only executed under the sandbox. If a user messed with app_name, they’d just create another sandbox.
if ! [ -e "${app_path}" ]; then
echo "ERROR: Could not find '${app_name}' in \$PATH."
exit 1
fi
It’s not really checking if it’s in $PATH. It checks existence of any file system object (not only file, that’s -f?). Maybe -x?
But then also begging the fundamental question, why should sandbox-app-launcher be limited to binaries in $PATH? Why not any executable whether in $PATH or not in $PATH? The user can execute it anyhow. If with or without sandbox, then the latter is better, no? Maybe I am missing something here still.
What about command line parameters to apps cat /path/to/file? Could you please compare with other wrappers (such as uwt) for proper getting name of binary and passing parameters?