To expand on that: sudo simply executes something as another user, limited by some configuration. It’s a very powerful tool, but its simplicity makes it very hard to use. You need to be incredibly careful in controlling what exactly is permitted, and the environment it is called in, to both prevent accidental privilege escalation while still giving all users involved enough permissions to do what they need. Furthermore, if something is not possible as a specific user, the application is almost certainly designed for it to be impossible - limiting the permissions of a specific user is a deliberate choice, messing with that breaks the entire design.
All of this is less bad when you’re doing just a small task manually, but the moment you script it it becomes fairly easy to misuse. Honestly even using it manually is often a mistake, many novices break their systems that way. NixOS is luckily somewhat robust to this thanks to the nix store being read-only even to the root user, but you can definitely still screw some stuff up.
sudo should only be used if you’re absolutely certain of every single side effect it has, and that there is no better way to achieve what you want. I’d say making flatpak apps world-writeable is definitely not within the realm of knowing every single side effect it has - imagine a user from a sandbox that ends up executing malicious code overwriting your spotify executable with a keylogger, for example. This kind of stuff completely breaks the assumptions around user management that allow distributions and applications to manage security layers for you. It kind of defies the purpose of using flatpak altogether.
Even if sudo doesn’t cause any actual problems, it’s quite hard to use in scripts, because by design it requires some authentication from the user. This means that your scripts now need to run interactively - which makes many use cases completely impossible.
You could configure sudo to permit very specific commands, or give it some kind of long cache, but now we’re back to compromising security.
The point is: sudo should only ever be used to perform one-off administrative tasks with a very specific scope. Don’t use it as a crutch to “fix” file permissions when you aren’t sure why they are the way they are, and definitely don’t script it to make such changes.
If you really need to execute something as another user, it’s best to make that user do that in the first place via something more controlled like systemd. Managing disk mounts is, for example, best done via udisks. If you need to execute something as another user, home-manager is definitely not the right place to do that, since it’s configuration for your user’s home directory. It should never be changing files not owned by your user.
