[Feature request] follow xdg variables.

[Samueru-sama]

Hi @mgord9518 thank you for all the recent work and fixes done to aisap. I really like how this is turning out.

Suggestion

Make aisap follow xdg user dirs variables instead of using hardcoded values.

For example instead of XDG_DOCUMENTS_DIR being hardcoded as ~/Documents aisap should check if it defined in user-dirs.dirs else it defaults to using ~/Documents.

This also applies to the xdg base dir variables, that is for example check if the $XDG_CONFIG_HOME variable is defined, else default to using ~/.config

Use case

This allows using aisap easily on non English systems. As the default permissions assume that you have a ~/Documents, ~/Videos, directory instead of using their name in other languages in user-dirs.dirs.

And following the xdg base dir variables is for me xd, as I have all of those defined inside ~/.local.

---

This can also be extended beyond what the xdg spec calls, for example instead of having ~/Games and ~/ROMs rules like it happens with the emulators, aisap can instead allow and look for XDG_GAMES_DIR which if not set defaults to ~/Games.

That way the user can define their XDG_GAMES_DIR to whatever name they want and aisap automatically uses that location instead.

XDG_GAMES_DIR is not something I invented, if you google it you will see that several people already use it and want it in the spec as well.

iirc NixOS did something similar with XDG_BIN_HOME, it isn't part of the spec but it is very useful to have it as that allows moving and renaming that location.

Possible issue

aisap has to check that none of these variables get defined as $HOME or $HOME/ as we discovered that can happen when testing in am, hopefully it is not too big of a deal to add such check.

[mgord9518]

I 100% agree on moving away from the hard coding, my original reasoning in doing this was so Applications only saw the "default" versions of those directories to hopefully make the user harder to track but I'm not sure I want to keep it like that. In such cases like you're talking about where the user is accustomed to XDG directories in a different language, it may be annoying and confusing. I've been doing research on XDG-portals, and I believe they shouldn't be crazy hard to implement in aisap, so that might resolve this issue on its own

As for the checking, I don't think it should be a huge security risk since the user themselves would have to set it, but some extra forethought never hurts. Can you link to the issue with setting these variables in AM?

[Samueru-sama]

I 100% agree on moving away from the hard coding, my original reasoning in doing this was so Applications only saw the "default" versions of those directories to hopefully make the user harder to track but I'm not sure I want to keep it like that. In such cases like you're talking about where the user is accustomed to XDG directories in a different language, it may be annoying and confusing. I've been doing research on XDG-portals, and I believe they shouldn't be crazy hard to implement in aisap, so that might resolve this issue on its own

Interesting, I really don't know how those portals work though, I think I don't even have them installed xd.

As for the checking, I don't think it should be a huge security risk since the user themselves would have to set it, but some extra forethought never hurts. Can you link to the issue with setting these variables in AM?

ivan-hc/AM#677 (comment)

ivan-hc/AM#675 (comment)

And here is how am handles it all: https://github.com/ivan-hc/AM/blob/main/modules/sandboxes.am

Of course if the user allows access to $HOME that's them that explicitly gave it, but the possibility that giving access to for example XDG_DESKTOP_DIR could result in that turning into $HOME/ is a an issue as they are likely not aware of it. I actually don't know if flatpak has measures against this.

The resulting sandbox script has these checks, for example for xdg-documents:

XDG_DOCUMENTS_DIR="$(xdg-user-dir DOCUMENTS 2>/dev/null)"
if [ "$XDG_DOCUMENTS_DIR" = "$HOME" ] || [ "$XDG_DOCUMENTS_DIR" = "$HOME/" ]; then XDG_DOCUMENTS_DIR=""; fi
--rm-file "${XDG_DOCUMENTS_DIR:-~/Documents}"

And it asks the user if they want to give access to xdg-desktop, if they say yes the last part of the script gets turned into this:

--add-file "${XDG_DOCUMENTS_DIR:-~/Documents}":rw \

By default we always give read and write access when yes is given, I haven't bothered to ask if they want to allow read only access as I feel like we have too many questions when sandboxing already lol.

[mgord9518]

This is something I'll try to implement in the new aisap-zig version I've been working on, but yeah it's a bit difficult to balance features and too much complexity. I think I'll end up making a GUI configuration tool, which should make messing with these options a lot easier

[Samueru-sama]

This is something I'll try to implement in the new aisap-zig version I've been working on, but yeah it's a bit difficult to balance features and too much complexity. I think I'll end up making a GUI configuration tool, which should make messing with these options a lot easier

Thanks, I ended up simplifying how to get the xdg user dirs and make sure to unset it if it equals to home, and I should probably turn that into a case statement that checks them against more spooky locations but that would be getting overkill lol.

For what we are doing the CLI is more than enough, I think something similar to the interactive questions we have would be great to have native in aisap as well, I'm really not sure if a GUI is needed because it is very likely that it will be just a bunch of toggles on a list like flatseal and to be honest that can be achieved on the CLI as well, but I do get not all people like using the terminal though.

Right now the only issue we have is that a sandboxed appimage can't launch another appimage, and some weird issue with multiple dbus on /tmp that is worked around with ls /tmp/dbus* 2>/dev/null | head -1.

Thank you once again for making aisap.