8:50 p.m.
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?
7 a.m.
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
7:57 a.m.
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.
3:21 p.m.
On 06Nov2020 21:50, Tom Horsley <horsley1953(a)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(a)cskk.id.au>
5:16 p.m.
On 20201107 13:21:47, Cameron Simpson wrote:
On 06Nov2020 21:50, Tom Horsley <horsley1953(a)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.
{^_^}
6:47 p.m.
On 11/7/20 3:16 PM, jdow wrote:
On 20201107 13:21:47, Cameron Simpson wrote:
> On 06Nov2020 21:50, Tom Horsley<horsley1953(a)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.
7:28 p.m.
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 Horsley<horsley1953(a)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.
{^_-}
8:09 p.m.
On 07Nov2020 17:28, jdow <jdow(a)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 Horsley<horsley1953(a)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(a)cskk.id.au>
1:13 p.m.
On Sat, 7 Nov 2020 17:28:01 -0800
jdow <jdow(a)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
1:19 p.m.
On Sun, Nov 8, 2020 at 2:15 PM Dave Stevens <geek(a)uniserve.com> wrote:
On Sat, 7 Nov 2020 17:28:01 -0800
jdow <jdow(a)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.
1:41 p.m.
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(a)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(a)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
4:34 p.m.
On 20201108 11:33:30, Dave Stevens wrote:
On Sun, 8 Nov 2020 14:19:53 -0500
Jamie Fargen <jamie(a)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.
{^_^}
1:36 p.m.
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?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:05 p.m.
On Sun, 8 Nov 2020 14:36:03 -0500
Matthew Miller <mattdm(a)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
4:36 p.m.
On Sun, Nov 08, 2020 at 12:05:14PM -0800, Dave Stevens wrote:
Matthew Miller <mattdm(a)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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:51 p.m.
On 08Nov2020 11:13, Dave Stevens <geek(a)uniserve.com> wrote:
On Sat, 7 Nov 2020 17:28:01 -0800
jdow <jdow(a)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(a)cskk.id.au>
3:49 p.m.
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.)
8:44 a.m.
On Sat, Nov 7, 2020 at 7:47 PM Samuel Sieb <samuel(a)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 Horsley<horsley1953(a)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?
11:40 a.m.
On Sun, Nov 8, 2020 at 9:44 AM Mauricio Tavares <raubvogel(a)gmail.com> wrote:
On Sat, Nov 7, 2020 at 7:47 PM Samuel Sieb <samuel(a)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 Horsley<horsley1953(a)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
3:47 p.m.
On Sat, Nov 7, 2020 at 10:22 PM Cameron Simpson <cs(a)cskk.id.au>
wrote:
On 06Nov2020 21:50, Tom Horsley <horsley1953(a)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...
3:50 p.m.
On 09Nov2020 22:47, Tom H <tomh0665(a)gmail.com> wrote:
On Sat, Nov 7, 2020 at 10:22 PM Cameron Simpson <cs(a)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(a)cskk.id.au>
1:56 p.m.
On Mon, Nov 9, 2020 at 10:50 PM Cameron Simpson <cs(a)cskk.id.au> wrote:
On 09Nov2020 22:47, Tom H <tomh0665(a)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.
1289
days inactive
1292
days old
22 comments
12 participants
participants (12)
-
Cameron Simpson -
Dave Stevens -
Jamie Fargen -
jdow -
Joe Zeff -
Matthew Miller -
Mauricio Tavares -
Patrick O'Callaghan -
Sam Varshavchik -
Samuel Sieb -
Tom H -
Tom Horsley