Looking for opinions on authorization frameworks for Pallet

[Rainer Müller]

Hello Kyle,

On 2015-08-05 20:14, Kyle Sammons wrote:
> ** Option 0: Do nothing; leave the current code in place, but continue
> to ignore it; require the user to run it with superuser privileges;
> 
> Pros:
> --------
> 1. Easiest to implement; requires no changes to the current code,
> allowing me to add more features to Pallet, and remove more bugs.
> 
> Cons:
> --------
> 1. Still requires a certificate. Using a modern authorization framework
> requires the use of a self-signed certificate, which highly complicates
> the project build process, making writing a Portfile much harder.

That's right. I don't think it is unsolvable, just a lot of work to
figure it out, but the solution we implement here could also be used for
other applications. It might be worth the effort to have this.

> 2. Still requires running Pallet with superuser privileges.
> 
> 3. Insecure. The entire application will be running as a superuser, so
> any vulnerabilities that are exploitable will allow a hacker to run as
> root.

There would not be any new functionality in the graphical frontend that
could not also be exploited in 'sudo port' from the command line, right?

> ** Option 2. Remove all authorization frameworks from Pallet, and
> require the user to run it with superuser privileges:
> 
> Pros:
> --------
> 1. Pretty easy to implement. I could implement this solution in a day or
> two, allowing me to add more features to Pallet, and remove more bugs.
> 
> 2. Doesn't require a certificate. Using a modern authorization framework
> requires the use of a self-signed certificate, which highly complicates
> the project build process, making writing a portfile much harder.
> 
> 3. Easiest to support. Running an application with "sudo" will really
> never be deprecated, and will work on every OS X version.

Would I have to type 'sudo pallet'? Will I be able to start the
application from an app bundle?

> 4. Smallest code-base.
> 
> Cons:
> ---------
> 1. Insecure. The entire application will be running as a superuser, so
> any vulnerabilities that are exploitable will allow a hacker to run as
> root.

See above.

Rainer