queer / boxxy Goto Github PK

If you have a config with rules you want to match at any context, but only certain applications, it doesn't seem to work correctly. For example:

  - name: "redirect ssh from ~/.ssh to ~/.config/ssh"
    target: "~/.ssh"
    rewrite: "~/.config/ssh"
    mode: "directory"
    only:
       - "/usr/bin/ssh"
       - "/usr/bin/rsync"
  - name: "test"
    target: "~/test1"
    rewrite: "~/test2"
    mode: "directory"
    only:
       - "/usr/bin/test"

Running boxxy test would also match against the ssh rule, because an unspecified context is treated as any context, which of course always matches, and that's all it takes for a rule to be considered matching.

The behavior I would expect is that if you specify an only restriction but not a context restriction, the only would take precedence. This effectively takes the behavior back to before the context feature existed if you don't use it, which maintains backwards compatibility with old configs as well.

Sorry for the flippant title.

The issue is that programs running under boxxy see all users as nobody, with the exception of the user launching the program. For instance:

# proving my root filesystem isn't completely broken
➜  ~ ls -l /
total 56
lrwxrwxrwx   1 root root     7 Jan 31 21:51 bin -> usr/bin
drwxr-xr-x   4 root root  4096 Jan  1  1970 boot
drwxr-xr-x  21 root root  4240 Jun  5 20:20 dev
drwxr-xr-x  76 root root  4096 Jun  5 20:20 etc
drwxr-xr-x   4 root root  4096 May 28 11:38 home
lrwxrwxrwx   1 root root     7 Jan 31 21:51 lib -> usr/lib
lrwxrwxrwx   1 root root     7 Jan 31 21:51 lib64 -> usr/lib
drwx------   2 root root 16384 Apr 30 13:59 lost+found
drwxr-xr-x   3 root root  4096 May 28 10:04 media
drwxr-xr-x   2 root root  4096 Jan 31 21:51 mnt
drwxr-xr-x   8 root root  4096 May 12 21:35 opt
dr-xr-xr-x 287 root root     0 Jun  5 20:20 proc
drwx------   6 root root  4096 May 27 23:27 root
drwxr-xr-x  25 root root   580 Jun  5 20:20 run
lrwxrwxrwx   1 root root     7 Jan 31 21:51 sbin -> usr/bin
drwxr-xr-x   4 root root  4096 Apr 30 14:03 srv
dr-xr-xr-x  13 root root     0 Jun  5 20:20 sys
drwxrwxrwt  12 root root   280 Jun  5 20:23 tmp
drwxr-xr-x  10 root root  4096 May 28 21:52 usr
drwxr-xr-x  12 root root  4096 May 30 17:06 var

# now let's see what boxxy sees
➜  ~ boxxy ls -l /
 INFO  boxxy > loading rules from /home/alex/.local/config/boxxy/boxxy.yaml
 INFO  boxxy > loaded 5 total rule(s)
 INFO  boxxy::enclosure > applying 5 rules
 INFO  boxxy::enclosure > applying rule [...]
 INFO  boxxy::enclosure > boxed "ls" ♥
total 56
lrwxrwxrwx   1 nobody nobody     7 Jan 31 21:51 bin -> usr/bin
drwxr-xr-x   4 nobody nobody  4096 Jan  1  1970 boot
drwxr-xr-x  21 nobody nobody  4240 Jun  5 20:20 dev
drwxr-xr-x  76 nobody nobody  4096 Jun  5 20:20 etc
drwxr-xr-x   4 nobody nobody  4096 May 28 11:38 home
lrwxrwxrwx   1 nobody nobody     7 Jan 31 21:51 lib -> usr/lib
lrwxrwxrwx   1 nobody nobody     7 Jan 31 21:51 lib64 -> usr/lib
drwx------   2 nobody nobody 16384 Apr 30 13:59 lost+found
drwxr-xr-x   3 nobody nobody  4096 May 28 10:04 media
drwxr-xr-x   2 nobody nobody  4096 Jan 31 21:51 mnt
drwxr-xr-x   8 nobody nobody  4096 May 12 21:35 opt
dr-xr-xr-x 289 nobody nobody     0 Jun  5 20:20 proc
drwx------   6 nobody nobody  4096 May 27 23:27 root
drwxr-xr-x  25 nobody nobody   580 Jun  5 20:20 run
lrwxrwxrwx   1 nobody nobody     7 Jan 31 21:51 sbin -> usr/bin
drwxr-xr-x   4 nobody nobody  4096 Apr 30 14:03 srv
dr-xr-xr-x  13 nobody nobody     0 Jun  5 20:20 sys
drwxrwxrwt  12 nobody nobody   280 Jun  5 20:23 tmp
drwxr-xr-x  10 nobody nobody  4096 May 28 21:52 usr
drwxr-xr-x  12 nobody nobody  4096 May 30 17:06 var

# i can still see perms on my own files though
➜  ~ boxxy ls -l ~
 INFO  boxxy > loading rules from /home/alex/.local/config/boxxy/boxxy.yaml
 INFO  boxxy > loaded 5 total rule(s)
 INFO  boxxy::enclosure > applying 5 rules
 INFO  boxxy::enclosure > applying rule [...]
 INFO  boxxy::enclosure > boxed "ls" ♥
total 92
drwx------ 2 alex alex  4096 Jun  4 21:40 Downloads
drwx------ 5 alex alex  4096 May 13 20:41 Projects

This causes a few issues, such as not being able to sudo:

➜  ~ boxxy sudo echo
 INFO  boxxy > loading rules from /home/alex/.local/config/boxxy/boxxy.yaml
 INFO  boxxy > loaded 5 total rule(s)
 INFO  boxxy::enclosure > applying 5 rules
 INFO  boxxy::enclosure > applying rule [...]
 INFO  boxxy::enclosure > boxed "sudo" ♥
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

install.sh is misbehaving and wants to put it's binary to ~/bin AND NOT ~/.local/bin which is XDG standard?

I want to use boxxy to install.sh to ~/.local/bin ?

Or might it be possible to customize the path in install.sh?

Anyway, cool idea. But too much work to write a config for every "misbehaving" application. A generic wrapper (scanning what bins are in your PATH) and a repository with predefined configs would be cool.

Look great :

• include a database with most common rules ?
• include a report mod for packager/maintainer/devs in order to improve their systems/soft/packages ? 

Hi, I can't find any license mentioned.

Would it be possible to support ARM64? Doesn't seem to compile on Asahi Linux.

https://stackoverflow.com/a/69081558

https://wiki.archlinux.org/title/XDG_Base_Directory

I recently tried to box a graphical application (Bitwig Studio) and it throws an error cannot open display :0.

Would it be possible to add support for graphical applications?

Is there a work-around?

Hi, thanks for this wonderful tool it managed to fix viber.

Anyway, I have a slight issue with it. Turns out that some applications refuse to be recognized properly by boxxy. Any idea what might be causing that? Thanks.

Command

RUST_BACKTRACE=full boxxy minetest

whereis

/nix/store/4qh85i0ydnna14p1fmigzlpndd357vzi-minetest-5.6.1/bin/minetest  (because nixOS)

It is in $PATH, however.

Error

Error: 
   0: cannot find binary path

Metadata

Backtrace

Backtrace:
   0: color_eyre::config::EyreHook::into_eyre_hook::{{closure}}
   1: eyre::capture_handler
   2: boxxy::enclosure::rule::Rule::applies_to_binary
   3: boxxy::enclosure::rule::BoxxyRules::get_all_applicable_rules
   4: boxxy::enclosure::Enclosure::run
   5: boxxy::main
   6: std::sys_common::backtrace::__rust_begin_short_backtrace
   7: std::rt::lang_start::{{closure}}
   8: std::rt::lang_start_internal
   9: main
  10: __libc_start_call_main
  11: __libc_start_main_alias_1
  12: _start

Config:

nikp123@NotThink ~> cat ~/.config/boxxy/boxxy.yaml | jq
{
  "rules": [
    {
      "context": [],
      "env": {},
      "mode": "directory",
      "name": "Rewrite Minetest game directory",
      "only": [],
      "rewrite": "~/.local/share/minetest",
      "target": "~/.minetest"
    },
    {
      "context": [],
      "env": {},
      "mode": "directory",
      "name": "Rewrite Viber image directory",
      "only": [
        "viber",
        "Viber"
      ],
      "rewrite": "~/Pictures/Apps/Viber/Desktop",
      "target": "~/Documents/ViberDownloads"
    },
    {
      "context": [],
      "env": {},
      "mode": "directory",
      "name": "Rewrite Viber state directory",
      "only": [
        "viber",
        "Viber"
      ],
      "rewrite": "~/.local/share/ViberPC",
      "target": "~/.ViberPC"
    }
  ]

Hi,

thanks for this nice project. It surely fills a need I didn't know I had. 😉 But now I find it really nice to be able to declutter my home dir.

But before I go along and throw it at every possible "intruder": do you know or have an estimate about the impact on the performance of the programs run within boxxy? And does it have any noticeable impact on the battery life of mobile devices?

Would be nice to know. :)

Hello,

I am trying to use boxxy with an AppImage packaged application (digikam),
and it fails at the early start of the application.

I have added the logs below.
Regards,

Yves.

./boxxy -l debug ~/app/digiKam-8.1.0-x86-64.appimage
 DEBUG boxxy::config > loading rules (not asked not to!)
 DEBUG boxxy::config > searching for boxxy config starting at /home/yves/App-sources/boxxy-v0.8.1-x86_64-unknown-linux-gnu
 DEBUG boxxy::config > checking for: /home/yves/App-sources/boxxy-v0.8.1-x86_64-unknown-linux-gnu/boxxy.yaml
 DEBUG boxxy::config > checking for: /home/yves/App-sources/boxxy.yaml
 DEBUG boxxy::config > checking for: /home/yves/boxxy.yaml
 DEBUG boxxy::config > checking for: /home/boxxy.yaml
 DEBUG boxxy::config > checking for: /boxxy.yaml
 DEBUG boxxy::config > ran out of parents to search!
 INFO  boxxy::config > loaded 0 total rule(s)
 DEBUG boxxy::enclosure > setup root
 DEBUG boxxy::enclosure::fs > setting up root for long-band-0214
 DEBUG boxxy::enclosure     > bind mount root rw
 DEBUG boxxy::enclosure::fs > bind mount "/" onto "/tmp/boxxy-containers/long-band-0214" as rw
 DEBUG boxxy::enclosure::fs > bind mount "/" onto "/tmp/boxxy-containers/long-band-0214"
 DEBUG boxxy::enclosure     > applying 0 rules
 DEBUG boxxy::enclosure     > chrooted to /tmp/boxxy-containers/long-band-0214
 DEBUG boxxy::enclosure > child stopped!
 DEBUG boxxy::enclosure::linux > mapped uids {
    Uid(
        1000,
    ): Uid(
        1000,
    ),
}
 DEBUG boxxy::enclosure::linux > mapped gids {
    Gid(
        1000,
    ): Gid(
        1000,
    ),
}
 DEBUG boxxy::enclosure        > finished setting up uid/gid mapping
 DEBUG boxxy::enclosure     > setting CHILD_SUBREAPER to 90184
 DEBUG boxxy::enclosure     > running command: "/home/yves/app/digiKam-8.1.0-x86-64.appimage"
 INFO  boxxy::enclosure     > boxed "/home/yves/app/digiKam-8.1.0-x86-64.appimage" ♥
 DEBUG boxxy::enclosure     > and spawn!
fusermount: mount failed: Operation not permitted

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory
 DEBUG boxxy::enclosure     > primary child exited with status 32512!
 DEBUG boxxy::enclosure     > execution finished!
 DEBUG boxxy::enclosure     > command exited with status: Child { stdin: None, stdout: None, stderr: None, .. }
 DEBUG boxxy::enclosure::fs    > cleaning up root for long-band-0214
 DEBUG boxxy::enclosure        > cleaning up 0 path(s) ♥
 DEBUG boxxy::enclosure        > exiting with status 0

It's a whole thing and a half, but with a lot of trickery, it might be doable: https://github.com/sevagh/namespace-experiments

Hi,

thanks for this cool tool. Maybe this is a noob question, but when I use boxxy I become user nobody. This isn't intended, right?

[clem@clem-t480s][~]$ boxxy whoami
 INFO  boxxy > loaded 1 rules
 INFO  boxxy::enclosure > applying rule 'redirect tmux config from ~/.tmux.conf to ~/.config/tmux/tmux.conf'
 INFO  boxxy::enclosure > redirect: ~/.tmux.conf -> ~/.config/tmux/tmux.conf
 INFO  boxxy::enclosure > boxed "whoami" ♥
nobody

I'm on Fedora 37 and bash.

Now that boxxy scan is in, it might be useful to also control environment variables so that misbehaving programs can be better-controlled than just transparently mounting files over what they expect.

Boxxy is not so convenient to use inside pipelines and call from other programs because it loads the configuration from a hardcoded path.
It would be much more convenient if the path to the config could be specified via optional cli argument.
It would also be convenient if the rules could be passed directly through arguments, without using a config at all.

I've been wondering if it would be possible to run boxxy inside a Docker container as an extra layer.

I think it would be useful to force tools to write data inside a container to a tmpfs, etc.

Right now, targeting read-only files or directories fails (with a panic).

Supporting this case would be useful for (examples):

• re-map the location of configuration files that are not supposed to be modified by the target application
• provide modified/program-local system configuration files for a specific target application

In any case, this should probably not fail with a panic!

As discovered in #8, sometimes it's necessary to run xhost + or similar. This should be handled transparently if possible.

I'm trying to clean up the mess of configuration directories left by VS Code and I was wondering if it would be possible to use "nested" rewrite rules. I tested with this configuration:

rules:
- name: VS Code extension manifest
  mode: file
  target: ~/.vscode/extensions/extensions.json
  rewrite: ~/.config/vscode/extensions.json
- name: VS Code extensions
  mode: directory
  target: ~/.vscode/extensions
  rewrite: ~/.cache/vscode/extensions

And it looks like VS Code is using the file in ~/.cache/vscode/extensions/extensions.json despite the other rule being more "specific". It'd be nice if it was bound to ~/.config/vscode/extensions.json instead and that the rest of the files inside of extensions/ were bound to ~/.cache/vscode/extensions.

Would this be possible/not too complicated to implement in boxxy?

Thanks for the project btw, it's working great for me ❤️

While risking to be nit-picky:
tmux 3.1+ (e.g. included in Debian 11 "bullseye") is capabable of using ~/.config/tmux/tmux.conf
https://unix.stackexchange.com/questions/644819/is-it-possible-to-move-tmux-conf-to-config-folder

(Apart from that, the general idea of boxxy seems communicated good enough. Cheers!)

Librewolf creates ~/.librewolf and ~/.mozilla. Using boxxy, these are redirected to their set locations, but empty directories are still created at those paths.

boxxy.yaml:

rules:
- name: Mozilla
  target: ~/.mozilla
  rewrite: ~/.local/config/mozilla
  mode: directory
- name: Librewolf
  target: ~/.librewolf
  rewrite: ~/.local/config/librewolf

I love this tool already, and I integrate it into my dev environments using Nix. However, it's a little too noisy for my liking when I'm using the tool repeatedly. Is it feasible to create a flag to reduce boxxy's output to the terminal?

Hello,

galaxy is a bioinformatics processing server and workflow thingie. It runs on python's uwsgi .

The software has two modes : --daemon and foreground (when not run under apache/ngnix)

When running with --daemon, the original uwsgi process forks and exits , which undoes all the work boxxy has done.

here it is after starting with /opt/galaxy/bin/boxxy /opt/galaxy/21.09/run.sh --daemon

here it is after starting with /opt/galaxy/bin/boxxy /opt/galaxy/21.09/run.sh (stay in foreground)

pstree says that the environment should be boxxed

apologies if this a wrong ticket! this tool is gonna save a lot of headaches in HPC clusters, where the sysadmins either cannot change the app (cuz the original company just says "no") or the grad student has moved on after finishing their degree/postdoc

This would allow ex. project developers to distribute pre-made rules to help control the behaviour of related tools.

If you were to have multiple binaries of the same name in your path (say, if you wanted to provide wrappers around binaries in /usr/bin in ~/.local/bin), then you may want to be able to specify a rule more exactly than just by the name of the binary.

If you had a config like this:

rules:
  - name: "test rule"
    target: "~/test"
    rewrite: "~/othertest"
    mode: "directory"
    only:
      - "/usr/bin/test"

calling boxxy like this: boxxy /usr/bin/test would fail to match the rule. It would match when called as just boxxy test though, which feels a bit unintuitive.

It seems to be because it's comparing the invoking name to just the file name of the rule in applies_to_binary().

More helpful behavior might be to apply the rule generically to any binary path if written plainly (with the only being the same as the file name, like test), or apply it specifically if it's a full path name (like /usr/bin/test)? Just comparing against the filename of the invoking command as well would be an improvement, though.

I appreciate your work on the project. It's nice to be able to tidy up my home directory a bit more.

If you pass a program that doesn't exist to boxxy, you get an error in rule.rs about failing to find the binary path, and a bunch of output indicating it may be a problem with boxxy itself:

~> boxxy testt
 INFO  boxxy > loaded 2 rule(s)
Error: 
   0: cannot find binary path

Location:
   src/enclosure/rule.rs:136

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Consider reporting this error using this URL: https://github.com/queer/boxxy/issues/new?title=%3Cautogenerated-issue%3E&body=%23%23+Error%0A%60%60%60%0AError%3A+%0A+++0%3A+cannot+find+binary+path%0A%60%60%60%0A%0A%23%23+Metadata%0A%7Ckey%7Cvalue%7C%0A%7C--%7C--%7C%0A%7C**version**%7C0.3.6%7C%0A

This should probably be explicitly checked for before testing against rules at all, and present a more clear, less generic error.