|
|
On 2/8/07, Gary Grossman <ggrossman@xxxxxxxxxxxxx> wrote: > Hi Alon, > > This GUI does use the management interface to communicate with the > openvpn daemon. The privileged account access is merely for starting > the openvpn daemon. Oh... this is good to know! I did not understand this from the description... Sorry. > The GUI does not need to run as root. There is a setuid-root > executable "gopenvpnstart" which does nothing but start openvpn and > contains a minimal amount of code. I modeled this after the > Tunnelblick GUI on MacOS, which uses a setuid root executable called > "openvpnstart" to start up OpenVPN. I understand... But then the user can choose any configuration he wishes and may modify computer behavior as a result of specific settings. sudo is good because it allows the administrator to enable the user to execute specific commands such as openvpn with specific configuration. > If you don't want to use the setuid executable, you can #define > USE_GKSU in the code and then it will use gksu to ask you for root > access. (gksu instead of sudo since this is a Gtk GUI app.) No... I did not mean that the root password should be available for the user. > Would you prefer to start the openvpn daemon yourself with sudo? I think that the user should be able to specify a command for start and a command for stop for each connection. People may use your sudo wrapper or pre-configured sudo command. For example at Gentoo you start/stop OpenVPN as a service (/etc/init.d/openvpn.[connection] start/stop), I guess other distribution has a similar mechanism. So administrator adds the following to sudoers: %users ALL=(ALL) NOPASSWD: /etc/init.d/openvpn.work1 And configure your GUI to use: start:sudo /etc/init.d/openvpn.work1 start stop:sudo /etc/init.d/openvpn.work1 stop > I imagine there are usage scenarios like smart cards that I haven't > thought about since I don't do them myself. Have you implemented the need-ok? Does your state machine support of several password and need-ok at session life? Some other issues from kovpn experience... Idle (disconnected) state should be OpenVPN hold state. I hope disconnect is implemented as signal SIGUSR1 and not daemon stop. Should have an option to send signal SIGUSR1 when the program exists (To force disconnect when user logoff). need-ok dialog cancel should also send SIGUSR1. When daemon is down, don't consume a lot of CPU trying to connect. Best Regards, Alon Bar-Lev. ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |