Dear Fedora Developers, Fedora 32 Xfce 4.14 NetworkManager-1.22.10-1.fc32.x86_64 # grep USERCTL /etc/sysconfig/network-scripts/ifcfg-eno2 USERCTL=yes $ /usr/libexec/nm-ifdown eno2 Error: failed to load connection: access denied. $ ifdown eno2 Error: failed to load connection: access denied. GRRRRR Please fix. Many thanks, -T
Use "nmcli c down eno2" instead.
(In reply to Samuel Sieb from comment #1) > Use "nmcli c down eno2" instead. Hi Sam, That work wonderfully. Thank you! Will you be fixing nm-ifdown and ifdown too? Many thanks, -T
What do you mean? I didn't fix anything. "nmcli" is the command you should be using as a user. Why do you need the others?
Hi Sam, Maybe I misunderstand. My understanding was the USERCTL=yes was to work will all programs trying to up and down the interface, not just one specific program. In Fedora 31, any program could control the interface. This to me seems to be a regression. The documentation clearly states: https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/System_Administrators_Reference_Guide/sect-networkscripts-interfaces.html "USERCTL=yes This way a user can bring up the eth0 interface using the /sbin/ifup eth0-user command because the configuration options from ifcfg-eth0 and ifcfg-eth0-user are combined." It is completely agnostic as to "which" programs can control the interface, which was Fedora 31's behaviour. Maybe Fedora 32 make a change in this and the documentation has not caught up? -T
USERCTL means that users can control the interface, not just root. It's nothing to do with which programs can do it. That document appears to be an old draft one, but it's also not incorrect. Do you still have the network-scripts package installed? If so, then remove it and see if "ifdown" works after that.
Hi Sam, Made no difference. # dnf remove network-scripts ... Removed: chkconfig-1.11-6.fc32.x86_64 network-scripts-10.02-3.fc32.x86_64 network-scripts-ppp-2.4.7-35.fc32.x86_64 network-scripts-teamd-1.30-2.fc32.x86_64 $ ifdown eno2 Error: failed to load connection: access denied. $ /usr/libexec/nm-ifdown eno2 Error: failed to load connection: access denied. $ nmcli c down eno2 Connection 'eno2' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/11) $ nmcli c up eno2 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12) "USERCTL means that users can control the interface, not just root". That was my understanding too. Now do we have something to fix? -T
No, everything is working fine. ifup and ifdown are intended to be run as root. Maybe there was a permissions change at some point, but they don't work on my F31 either. As a user, you can use nmcli to control the interface, so USERCTL is working just fine.
Hi Sam, Do you have "network-scripts' installed on your F31? So far we USERCTL=yes restricted to only have one program. It needs to be all of them. OR the documentation updates to state only one program can do control the interface with USERCTL=yes. If ifup and ifdown are intended to run as root, they need to error out if run by a standard user. Since ifdown is a bash script, the following needs to be added: if [ -z "`/usr/bin/whoami | grep root`" ]; then echo "" echo 'Dude! You must be root to do this.' echo 'Exiting. Bummer ...' echo "" PressAnyKey exit 1 fi You might want t take out the "dude!" and the "Bummer" part. Maybe two things to fix now? -T
I removed network-scripts quite a while ago since it's deprecated and would give warnings if you used the commands from there. The NetworkManager ifup and ifdown still work fine as root. There is an alternatives setup, so if you remove the networks-scripts apckage, then the commands automatically become the NetworkManager ones. USERCTL=yes has nothing to do with the programs used. It tells NetworkManager that a user can control the connection and that is working as it should. As a user, you can control the connection using nmcli or the graphical interface tools. That documentation you found is a DRAFT and who knows how old it is. If you can find some official documentation that says to use ifdown, then that would need to be updated. Most tools intended to be used by root don't check the user, they just fail to access whatever they need to. There is nothing here to fix and I have no authority or access to fix anything related to this anyway.
Closest I could find was https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_ifcg_files "you can set the USERCTL directive to manage the device: If you set yes, non-root users are allowed to control this device." No mention of a particular program being required
Created attachment 1699224 [details] Virt manager log Virt manager log as requested
attached vir manager log to the wrong ticket. please delete it
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.