PyQt GUI support

[probonopd]

Would you be interested in an optional PyQt GUI?

Looks like trayicon.py and authentication.py would have to be adjusted. Possibly doable without too much hassle.

[ericbsd]

I am sorry to not have answered before.

What you have in mind?

I am not sure how GTK would fix well QT code, but I am open to that.

[ericbsd]

I guess no reply probably means you got something else working for you.

[probonopd]

Hello @ericbsd I would still be interested in a Qt frontend to the networkmgr backend. Unfortunately I don't have the time to work on it right now, but if someone does, please let us know.

[probonopd]

Hello @ericbsd I have finally started writing the Qt frontend, and it is beginning to work (i.e., I can see the network I am connected to):

However, there is one notable exception that may require a small architectural change: When I select menu items, I see messages like

FreeBSD% ~/helloSystem/networkmgr/networkmgr
ifconfig: down: permission denied
ifconfig: SIOCS80211: Operation not permitted
ifconfig: up: permission denied
ifconfig: down: permission denied
ifconfig: ioctl(SIOCSIFINFO_IN6): Operation not permitted

From looking at the code, it seems like networkmgr is running as root all the time. This is apparently not possible for the Qt equivalent of Gtk.StatusIcon, QSystemTrayIcon. It needs to run as the regular user that is also running the menu bar which is hosting the QSystemTrayIcon.

Hence, I think networkmgr should be changed so that it doesn't run as root (also in the Gtk version). This means that net_api.py needs to be reworked so that the appropriate commands are invoked with sudo, and sudoers would need to be adjusted accordingly to allow for those commands to be executed without the need for a password.

Would you be willing to make this change? Then I should be able to contribute a Qt frontend to this networkmgr repository rather than having to fork it.

---

On a semi-related note, did you consider using wpa_cli, does it have limitations compared to using the commands that networkmgr is using right now?

[ericbsd]

Hi, @probonopd

I started to use sudo to start networkmgr to avoid having service, ifconfig, and other commands in sudoers to avoid spamming system logs like /var/log/auth.log. That is the main reason I prefer to start networkmgr has to root.

If you have a way that would prevent spamming system logs I am fine with it.

[probonopd]

Adding Defaults !syslog to /usr/local/etc/sudoers prevents sudo from logging anything to /var/log/auth.log.

Replace !syslog with !log_allowed to stop logging successful attempts only, still logging denied attemps.

If you only want the logging disabled for certain commands, this is also possible.

[ericbsd]

Adding Defaults !syslog to /usr/local/etc/sudoers prevents sudo from logging anything to /var/log/auth.log.

Replace !syslog with !log_allowed to stop logging successful attempts only, still logging denied attemps.

If you only want the logging disabled for certain commands, this is also possible.

Sorry I completely forgot to reply.

How do you intend to add the sudo in the code?

[probonopd]

We could either make the commands that need to be invoked by normal users setuid root, or we could use sudo -A -E ... with SUDO_ASKPASS=/usr/local/bin/askpass as we are doing for a lot of things in helloSystem. It presents a GUI password dialog to the user.

[ericbsd]

We could either make the commands that need to be invoked by normal users setuid root, or we could use sudo -A -E ... with SUDO_ASKPASS=/usr/local/bin/askpass as we are doing for a lot of things in helloSystem. It presents a GUI password dialog to the user.

NetworkMgr is the only tool in GhostBSD that I wanted to avoid asking for a password in GhostBSD.

Could you explain what you mean about We could either make the commands that need to be invoked by normal users setuid root?

[probonopd]

Wikipedia explains it like this:

When the setuid or setgid attributes are set on an executable file, then any users able to execute the file will automatically execute the file with the privileges of the file's owner (commonly root) and/or the file's group, depending upon the flags set. This allows the system designer to permit trusted programs to be run which a user would otherwise not be allowed to execute.

So, if networkmgr needs to run tools normal users are not allowed to run without a password, then setting the setuid or setgid attributes on those tools may let normal users to run those tools without the need for entering a password.

So by setting sudo chmod 6755 /sbin/ifconfig, networkmgr does not need to be root anymore to use ifconfig.

[ericbsd]

I think I prefer to run networkmgr with sudo there network mgr deal with service to and there is more option coming the in the future that will deal.

Why you don't like to have networkmgr running with sudo it already does?

[probonopd]

Seems to me like it is best practice not to have long-running GUI processes run as root all the time, in order to reduce the attack vector.

[Peter2121]

AFAIK, it is impossible to use 'modern' AppIndicator protocol with an application started under sudo. To use networkmgr under Enlightenent (see https://github.com/ghostbsd/networkmgr/issues/32) I needed to go back to the old version that could be started under current user. Indeed, AppIndicator uses DBus, the application started under other account cannot communicate with the DE (or need some 'hacky' configuration I did not found).

[probonopd]

Indeed. Another reason not to run the GUI as root all the time. (Although I find it braindead that root cannot send D-Bus messages to all users, always found that hard to believe, but you seem to be confirming it.)

[ericbsd]

The problem is there is not only ifconfig. There is service, wpa_supplicant, dhclient, and others that I probably forgot.

I do not think FreeBSD will let NetworkMgr in the ports tree if we modify setuid or setgid. Even though I am a FreeBSD port committer, I am not sure I would like to push that solution to the ports tree. There must be and another way.