AquaProxy should set up and run as a dedicated _aquaproxy user

[Letterus]

By your default installation/default LaunchAgent plist files AquaProxy will be run as root. This basically means you’re going to surf the web as root when using the proxy. If there are any payloads which harm the AquaProxy service it will easily be able to harm your (old) system.

I also experienced I got failed TLS handshakes when running as root while it won’t using a regular user.

Best practice would be to create a new non-privileged user (without a shell even) during installation and use that to run AquaProxy. This can be done by adding to the LaunchAgent file:

<key>UserName</key>
<string>AquaProxyUser</string>

[Wowfunhappy]

By your default installation/default LaunchAgent plist files AquaProxy will be run as root. This basically means you’re going to surf the web as root when using the proxy. If there are any payloads which harm the AquaProxy service it will easily be able to harm your (old) system.

No, Aqua Proxy runs as the standard user! It’s started by a LaunchAgent, not a LaunchDaemon! It’s a system wide LaunchAgent which means it will start when any user logs in, but it’s not running as root!

(Specifically, it’ll run as the first user who logs in—if a second user logs in, the Launch Agent will try to start for that user as well, but it will gracefully fail since the port is in use, and you’ll just connect to the existing Aqua Proxy instance.)

If any of this does not seem to be working as expected, please reply here with information showing that it is running as root, because that’s not what I’m seeing!

[Wowfunhappy]

...on second thought, I'm opening this again, because while AquaProxy does not currently run as root, it still should set up and run as a dedicated _aquaproxy user. I've been avoiding this for a long time and I don't really know why, it's the established pattern for a system service. The current setup is a hack, and for no reason.

This is is still very low priority to fix because it has basically no functional benefit, and I find it personally tedious to implement and test.

[Letterus]

@Wowfunhappy Thank you for your immediate reply.

Yes, you are right. I removed the username part of the plist file, rebooted and aquaproxy was started as my user. So it being run as root was me using launchctl with sudo. Sorry for the fuss.

For the separate user: Yes, that would be even better and appreciated. Thank you.

[Wowfunhappy]

...If AquaProxy runs as _aquaproxy, which users are able to make changes to configuration files (flags.txt, headers.txt, no-mitm.txt, redirects.txt)? Obviously we could make this world-writable, but that partially defeats the purpose of this change, which is to lock down that stuff from less privileged users. On the other hand, I'd like admin users to be able to open these files in e.g. TextEdit to make quick edits, without having to use sudo.

Is there a middle path? (UNIX permissions kind of confuse me and I'd like to get better at this.)

[Letterus]

Files within the root path (f.e. /Library) should only be changed by admins using sudo. That’s the way it is, at least on machine files are installed having permissions root:wheel, 644. Don’t make anything configuring services world writable, I’d say.

[Wowfunhappy]

@Letterus There's an exception though: /Applications is in the root path but can be edited by admins. I'd like /Library/AquaProxy to work like that.

[Letterus]

Yes, you’re right, there are some directories working like that:

drwxrwxr-t   2 root  admin  7922  7 Mai 23:36 Fonts

So you need user root, group admin and permissions 664 for these files and the +t sticky bit on the directory.