I am running openSUSE 13.2. I cant execute commands like traceroute, ifconfig, etc as a normal user and can’t configure interfaces thru networkmanager as a normal user. The networkmanager demands password but the focus stealing print the password in other tile most of the time. When I try to edit an interface thru networkmanager the authentication tile goes behind interface tile and causes confusion. I have three routes with three active interfaces and I need to tweak things several time during the day. I can run wicked but it takes a long while (most time is used for restarting some networking services) to setup the interface from there.
How do I let normal user run ifconfig, traceroute, etc and how do I disable this networkmanager password auth; it maybe some feature but it isn’t making things convenient for me. I don;t know why it steals focus and prints root password in some other tile. I have set medium focus stealing provision in KDE control center. I believe this focus moving is a serious security flaw, people may post their passwords in clear text on some other active window and give it away for free.
It is polkit that sets the privileges for Network Manager. In particular, /etc/polkit-default-privs.standard contains a large number of default authorizations, including a number of NM-related entries. If you want to override any of these, then it is suggested to add custom authorization entries in /etc/polkit-default-privs.local, then run the following for the changes to take effect
/sbin/set_polkit_default_privs
For example, I have a couple of custom policies set
Configure sudo to allow ifconfig without password if you do not want to use su. But ifconfig does actions that require root priviliges so it must be run as root.
traceroute
I can run traceroue as plain user; what exact error do you get?
etc
Without knowing more details about what “etc” is the usual answer - either become root permanently (su) or use sudo to run “etc” as root.
and how do I disable this networkmanager password auth
One option is to create user connection. Downside is, it won’t be available until you log in. Otherwise you need to configure policy kit and grant yourself permissions to org.freedesktop.NetworkManager.settings.modify.system without authentication. Unfortunately this means writing small porgram in JavaScript … see man polkit(8) for some details.
Other programs are route, routel, routef, tracepath, rpcinfo. I tried creating user connections thru NetworkManager but during switching the panel crashed several times ( I can say it does that often). Even after user created interfaces I need to restart NetworkManager.service with systemctl.
I think I will take a look at polkit and see what can be done.
All of these work for me as normal user as long as you do not attempt to modify settings (which incidentally is true for ifconfig as well). I have to ask again - what exact errors you get from running rpcinfo as user?
Once created, it should only be necessary to select the desired connection.
I think I will take a look at polkit and see what can be done.
That is only required for system connection creation/editing. User connection pose no such problem. (I frequently create connections for access to various linknets as part of my work as a network engineer.)
Add the following to etc/polkit-default-privs.local
Here is some sample, it wants me to run these as a root -
Absolute path to 'rpcinfo' is '/sbin/rpcinfo', so running it may require superuser privileges (eg. root).
Absolute path to 'routel' is '/usr/sbin/routel', so running it may require superuser privileges (eg. root).
bor@opensuse:~> rpcinfo
Absolute path to 'rpcinfo' is '/sbin/rpcinfo', so running it may require superuser privileges (eg. root).
bor@opensuse:~> PATH=/sbin rpcinfo
rpcinfo: can't contact rpcbind: RPC: Remote system error - No such file or directory
bor@opensuse:~>
Before implementing any of these solutions, I’d advise taking a moment to consider what it may mean to break normal security policy.
Although it may not be immediately obvious, there is usually a reason why such apps normally require root permissions, in general any command which makes fundamental system changes is protected (these networking commands often have the ability to do more than just display existing configuration). If you enable the entire User Group to have access to these normally privileged functions, then any hack that can gain access to unprivileged permissions could conceivably gain root access to your machine (or at least make unexpected changes). If you grant elevated permissions specific to your normal logged in account, then anyone who can hack your system while you’re logged in would gain those root function access, and possibly more.
The normal “openSUSE” solution is to just open a root console and leave it open as long as needed (frowned upon in other distros). We generally frown on cookbook recipes that repeatedly invoke “sudo” in favor of our “always open” root console.
And, I strongly suspect this would solve your issues as well. Note that multiple consoles doesn’t even take much Desktop space, most openSUSE Desktops support tabbed console windows.
Bottom line: In openSUSE(different than other distros) - Long running root consoles are OK. Other distros - Long running root consoles BAD. Invoke sudo often as needed. All distros - Frown on elevating normal User permissions to transparently support root functionality.
I am not worried about security policy as such, these machines are behind robust OpenBSD router & firewall with <lan> – <router> – <squid> – <chrooted-privoxy> – <tor> and all dns is served by adsuck on the router. I don’t want to stay logged in as a root on any of these workstations because other people working on these machines will have full access. I believe there is some issue with broken environment in this case.