For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
On Fri, 2020-11-06 at 21:50 -0500, Tom Horsley wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
I do the same and it doesn't object. I do get a complaint about one Konsole session having two tabs open, but that's all. Maybe it's a Gnome thing (I use KDE and Konsole rather than xterm).
poc
Tom Horsley writes:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Perusing the manual pages, does
systemctl start reboot.target
work for you. If so, just create an alias for the reboot command in your root shell.
On 06Nov2020 21:50, Tom Horsley horsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Cheers, Cameron Simpson cs@cskk.id.au
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsley horsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Something sounds bass akwards here. IMAO only root or an account with sudo privileges should be able to reboot the machine. And root should be able to do this at any time.
{^_^}
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsleyhorsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Something sounds bass akwards here. IMAO only root or an account with sudo privileges should be able to reboot the machine. And root should be able to do this at any time.
I think you're misunderstanding. A root user is logged in and he's trying to reboot using his normal user. The current console user is generally allowed to reboot the system.
On 20201107 16:47:03, Samuel Sieb wrote:
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsleyhorsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Something sounds bass akwards here. IMAO only root or an account with sudo privileges should be able to reboot the machine. And root should be able to do this at any time.
I think you're misunderstanding. A root user is logged in and he's trying to reboot using his normal user. The current console user is generally allowed to reboot the system.
Thank you. That detail was not part of the context included. I'll go back to sleep now.
{^_-}
On 07Nov2020 17:28, jdow jdow@earthlink.net wrote:
On 20201107 16:47:03, Samuel Sieb wrote:
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsleyhorsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
[...]
I think you're misunderstanding. A root user is logged in and he's trying to reboot using his normal user. The current console user is generally allowed to reboot the system.
Thank you. That detail was not part of the context included. I'll go back to sleep now.
I think it was implicit, or inferrable. But I also missed this nuance.
Thanks Samuel, Cameron Simpson cs@cskk.id.au
On Sat, 7 Nov 2020 17:28:01 -0800 jdow jdow@earthlink.net wrote:
<stuff edited out>
and then others wrote
"The current console user is generally allowed to reboot the system."
why?? isn't that a giant security hole? just from mistakes, not to mention malice.
I just shut everything down. On reboot I logged in as dave, no apps running and only one user - me. typing reboot into bash restarted the machine.
Dave
On Sun, Nov 8, 2020 at 2:15 PM Dave Stevens geek@uniserve.com wrote:
On Sat, 7 Nov 2020 17:28:01 -0800 jdow jdow@earthlink.net wrote:
<stuff edited out>
and then others wrote
"The current console user is generally allowed to reboot the system."
why?? isn't that a giant security hole? just from mistakes, not to mention malice.
I just shut everything down. On reboot I logged in as dave, no apps running and only one user - me. typing reboot into bash restarted the machine.
If you have physical access it is trivial to gain root to the host, by booting into single user mode and changing the root password.
On Sun, 8 Nov 2020 14:19:53 -0500 Jamie Fargen jamie@fargenable.com wrote:
If you have physical access it is trivial to gain root to the host, by booting into single user mode and changing the root password.
you mean it won't work over ssh?
you mean it won't work over ssh?
Correct. If you ssh into a host, you need to be in a group with elevated privileges like whee, use sudo, or the root user to shutdown or reboot the system. I ssh'd into the same system with the same username and password with the F32 VM that I started up and both shutdown and reboot commands were restricted.
[jfargen@jwhlaptop ~]$ ssh jfargen@192.168.122.5 The authenticity of host '192.168.122.5 (192.168.122.5)' can't be established. ECDSA key fingerprint is SHA256:0940gk+TUrJhXF+Qu5q/FltdyARooEKy9M64oqi/zOE. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.122.5' (ECDSA) to the list of known hosts. jfargen@192.168.122.5's password: Web console: https://localhost:9090/ or https://192.168.122.5:9090/
Last login: Sun Nov 8 14:37:31 2020 [jfargen@localhost ~]$ shutdown -r now Failed to set wall message, ignoring: Interactive authentication required. Failed to reboot system via logind: Interactive authentication required. Failed to open initctl fifo: Permission denied Failed to talk to init daemon. [jfargen@localhost ~]$ reboot Failed to set wall message, ignoring: Interactive authentication required. Failed to reboot system via logind: Interactive authentication required. Failed to open initctl fifo: Permission denied Failed to talk to init daemon. [jfargen@localhost ~]$
Regards, -Jamie
On 20201108 11:33:30, Dave Stevens wrote:
On Sun, 8 Nov 2020 14:19:53 -0500 Jamie Fargen jamie@fargenable.com wrote:
If you have physical access it is trivial to gain root to the host, by booting into single user mode and changing the root password.
you mean it won't work over ssh?
There seems to be some linguistic misunderstandings here. What is a "root user"? I see that as somebody logged in as root. Anybody else has an account with sudo enabled, a sudoer. Anybody else is a user as is a sudoer when not prefixing commands with "sudo ". I interpreted "root user" to be somebody logged in using the root password not somebody who can run (some) root level commands using sudo instead of "su -l".
You have two classes of login, remote and local. Remote can be subdivided if you wish. It simply means the remote user cannot reach over a push a button to physically reboot the machine. (And at least one version of RedHat Linux I used even the local reboot to single user mode required a password. That restriction didn't last long as I recall.)
As a courtesy ANYBODY, root, sudoer, or user logged into a local (I can reach over a push a damn button if I have to) machine should be able to reboot, perhaps after some politeness mumbo-jumbo. ( "Fred, sue, marcy, meghan, george, johnj, and johna are logged in. Reboot anyway after warning them? y/n".) That allows the user about to pull the power switch a chance to be inhumanly polite. But, in the end, the reboot should happen. Perhaps if root is also logged in the mumbo-jumbo should be a little more serious.
Any user logged in remotely should not be able to reboot the machine, period, end of statement.
Any sudoer logged in remotely, when root is not logged, in should be able to reboot the machine after politeness mumbo-jumbo and rituals. If root is logged in I don't know what should happen. How much do you trust your root password or other account access. If you trust it implicitly, reboot should be prohibited even to sudoers. If you figure that the root account may get compromised and that "root" you see is not legitimate, then sudoers, people trusted more than most, should be able to reboot the machine hoping to catch it as it boots and close its doors. "Good luck".
If you log in as root or su -l in as root then shutting down the machine with "shutdown" should work with the standard politeness mumbo-jumbo and "shutdown now" should bring it down instantly.
Aside: Above this you might add a "shutdown (secret word here)" command that allows only a remote or local root login with the machine in a "dumb" state. The remote would be accepted only from one specific IP address range. Once logged in a specific sequence of commands would enable normal root access for that login. Then you can trouble shoot the machine and try to root out nasties before they manage to take the machine back away from you.
Now that there is a definition for local and remote logins and three account types what do YOU guys think should be the actions when "shutdown" is typed by some warm body at some keyboard somewhere that is somehow linked to any given machine?
Get specific and blow the generalities.
{^_^}
On Sun, Nov 08, 2020 at 11:13:31AM -0800, Dave Stevens wrote:
"The current console user is generally allowed to reboot the system." why?? isn't that a giant security hole? just from mistakes, not to mention malice.
What is the attack scenario you are envisioning here for this to be a security issue?
I just shut everything down. On reboot I logged in as dave, no apps running and only one user - me. typing reboot into bash restarted the machine.
Do you feel this is significantly different from picking "Reboot" from the menu of a GUI environment?
On Sun, 8 Nov 2020 14:36:03 -0500 Matthew Miller mattdm@fedoraproject.org wrote:
On Sun, Nov 08, 2020 at 11:13:31AM -0800, Dave Stevens wrote:
"The current console user is generally allowed to reboot the system." why?? isn't that a giant security hole? just from mistakes, not to mention malice.
What is the attack scenario you are envisioning here for this to be a security issue?
denial of service?
I just shut everything down. On reboot I logged in as dave, no apps running and only one user - me. typing reboot into bash restarted the machine.
Do you feel this is significantly different from picking "Reboot" from the menu of a GUI environment?
ibid
On Sun, Nov 08, 2020 at 12:05:14PM -0800, Dave Stevens wrote:
Matthew Miller mattdm@fedoraproject.org wrote:
On Sun, Nov 08, 2020 at 11:13:31AM -0800, Dave Stevens wrote:
"The current console user is generally allowed to reboot the system." why?? isn't that a giant security hole? just from mistakes, not to mention malice.
What is the attack scenario you are envisioning here for this to be a security issue?
denial of service?
Turning of your own machine is technically a denial of service, sure. But as the headline issue here shows, you're prompted for authentication if another account is logged in. (This is the case for example when user-switching to share a machine, or when someone is logged in remotely.)
If you do have a system where physical login access is available but the machine is also acting as a server, and you don't have 100% trust for the people with that physical access, you should configure the system to be more locked-down in a variety of ways, including this one.
On 08Nov2020 11:13, Dave Stevens geek@uniserve.com wrote:
On Sat, 7 Nov 2020 17:28:01 -0800 jdow jdow@earthlink.net wrote:
<stuff edited out>
and then others wrote "The current console user is generally allowed to reboot the system."
why?? isn't that a giant security hole? just from mistakes, not to mention malice.
Cannot the console user type Ctrl-Alt-Del anyway? So I'm not sure this is of itself a security hole. Except in as much as it relies of software correctly deducing the physical presence of the console user at the console, and mucking that up would indeed be a security hole.
So I think of itself it seems half legit, but it increases the attack surface.
Cheers, Cameron Simpson cs@cskk.id.au
On 11/8/20 12:13 PM, Dave Stevens wrote:
I just shut everything down. On reboot I logged in as dave, no apps running and only one user - me. typing reboot into bash restarted the machine.
Does your regular user have wheel? If so, try creating a test user without it and see what happens. (None of my users have wheel, as I installed Fedora with a root password and have no use for wheel. I'm asking, as I know that most Linux users don't do things this way.)
On Sat, Nov 7, 2020 at 7:47 PM Samuel Sieb samuel@sieb.net wrote:
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsleyhorsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Something sounds bass akwards here. IMAO only root or an account with sudo privileges should be able to reboot the machine. And root should be able to do this at any time.
I think you're misunderstanding. A root user is logged in and he's trying to reboot using his normal user. The current console user is generally allowed to reboot the system. __
Since when is a non-root user allowed to reboot "from another terminal" (quoted from original email) window?
On Sun, Nov 8, 2020 at 9:44 AM Mauricio Tavares raubvogel@gmail.com wrote:
On Sat, Nov 7, 2020 at 7:47 PM Samuel Sieb samuel@sieb.net wrote:
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsleyhorsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has
an
option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
Something sounds bass akwards here. IMAO only root or an account with sudo privileges should be able to reboot the machine. And root should
be
able to do this at any time.
I think you're misunderstanding. A root user is logged in and he's trying to reboot using his normal user. The current console user is generally allowed to reboot the system. __
Since when is a non-root user allowed to reboot "from another terminal" (quoted from original email) window? ______________________________
The keyword here is "local aka physical". If a non-root user is logged into a host on a local terminal most likely with a keyboard and mouse, not a psuedo terminal like an Xwindows Session or ssh. The user, even without sudo access or a member of an elevated priviledge group like the wheel group, can shutdown the host. To confirm my memory, just tested this by spinning up an F32 VM, getting on the terminal via virt-manager, logging in as a regular user and testing both the shutdown and reboot commands, the both worked.
I think you will have to dig into the PAM config to restrict local users from issuing shutdown / reboot commands.
Regards, -Jamie
On Sat, Nov 7, 2020 at 10:22 PM Cameron Simpson cs@cskk.id.au wrote:
On 06Nov2020 21:50, Tom Horsley horsley1953@gmail.com wrote:
For as long as I can remember I've run dnf update in a root xterm and when all the akmod activity and wot-not is finished, I've run reboot from another terminal.
Now, it won't reboot "because root is logged in".
Gah! Who cares if root is logged in?
Can I disable this helpful feature any way?
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
"w" and "who" look at "/var/run/utmp".
"last" looks at "/var/log/wtmp".
You can use "xterm*utmpInhibit: true" in "~/.Xresources" to prevent xterm from updating utmp. But it's hard to believe that this is what's messing with the other Tom H's system. Maybe...
On 09Nov2020 22:47, Tom H tomh0665@gmail.com wrote:
On Sat, Nov 7, 2020 at 10:22 PM Cameron Simpson cs@cskk.id.au wrote:
Dunno, but maybe you can disable what it measures. Do your xterms make entries in wtmp (listed by "w" and "who")? Is so, ISTR that xterm has an option to not do that (look for "wtmp" in the manual IIRC). See if disabling that helps.
"w" and "who" look at "/var/run/utmp".
"last" looks at "/var/log/wtmp".
Thank you for this correction, brain fade on my part.
You can use "xterm*utmpInhibit: true" in "~/.Xresources" to prevent xterm from updating utmp. But it's hard to believe that this is what's messing with the other Tom H's system. Maybe...
Cheers, Cameron Simpson cs@cskk.id.au
On Mon, Nov 9, 2020 at 10:50 PM Cameron Simpson cs@cskk.id.au wrote:
On 09Nov2020 22:47, Tom H tomh0665@gmail.com wrote:
"w" and "who" look at "/var/run/utmp".
"last" looks at "/var/log/wtmp".
Thank you for this correction, brain fade on my part.
You're welcome. The only reason that I remember this mismarch between _w_ho and _w_tmp is that I had a brain fart in a discussion at work and ran "ktruss who" (on NetBSD) to find out which *tmp file was being read.
-
Cameron Simpson -
Dave Stevens -
Jamie Fargen -
jdow -
Joe Zeff -
Matthew Miller -
Mauricio Tavares -
Patrick O'Callaghan -
Sam Varshavchik -
Samuel Sieb -
Tom H -
Tom Horsley