Re: can't login as root
From: Nico Kadel-Garcia (nkadel_at_verizon.net)
Date: 09/27/03
- Next message: Peter T. Breuer: "Re: can't login as root"
- Previous message: Peter T. Breuer: "Re: can't login as root"
- In reply to: Michael C.: "Re: can't login as root"
- Next in thread: Peter T. Breuer: "Re: can't login as root"
- Reply: Peter T. Breuer: "Re: can't login as root"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 27 Sep 2003 20:04:47 GMT
Michael C. wrote:
> On Sat, 27 Sep 2003 18:37:16 GMT,
> Nico Kadel-Garcia <nkadel@verizon.net> wrote:
>
>> Peter T. Breuer wrote:
>>
>>
>>>knocte <knocte@no-spam-please-hotmail.com> wrote:
>>>
>>>
>>>>Isn't there any workaround? I just want to login as root from console!
>>>>Just that!
>>>
>>>
>>>Don't do that! That is real ignorance speaking. There is nothing you
>>>should ever want to log in as root for.
>>>
>>>Peter
>>
>>
>> Says Peter Breuer, once again trying to sneeze his brains out his ears.
>> Folks, this guy gives vaguely technical sounding advice in such absolute
>> terms that it's just plain wrong.
>>
>> Things that may require root from console include:
>>
>> 1: Resetting network configurations on systems that use NIS or LDAP to
>> provide user accounts.
>
>
> If users can't log in, I'd be using maintenance mode. (Single user)
Which you may or may not be able to get to without the boot loader
password and/or BIOS password for booting with CD. Yea, with many
motherboards you can flush the BIOS password and reset the configuration
to default by hitting the "reset" button 3 times in a row during reboot,
but that's kind of rude.
Been there, done that.
>> 2: Logging directly into systems with the root password when you're the
>> only one who knows it and you don't have a local user account on the
>> machine (common in workgroup environments).
>
>
> The only reason they don't have a local account is they were too lazy to
> create it. If you're root you create and maintain a user account.
No, local root accounts are themselves a hazard. They create an
*additional* set of root level accounts that have to be maintained, and
make changing the site-wide root access even more awkward.
Been there, done that.
>> 3: Fixing corrupted /etc/passwd or /etc/shadow files that have disabled
>> other user logins.
>
>
> Maintenance mode.
See above. Maintenance mode is not always accessible.
>> 4: Fixing PAM or Kerberos when they got messed up.
>
>
> Maintenance mode.
See above.
>> 5: Logging into a known good account when your root-equivalent or sudo
>> account has had its configuration messed up (such as a mistake in the
>> .bashrc file).
>
>
> You could check it before logging out. No I don't recall how, but I
> know it can be done (and should be.)
Yes, it should be. Screwups happen. "su -l" is one way to test them,
another is to switch to another virtual console with "Ctrl-Alt-F2" and
try logging in from there. However, some such failures are time or setup
dependent. It may work depending on what services are mounted or
running, and system upgrades can break them as well.
Been there, done that.
>> 5: Certain amazingly stupid software installation tools that do things
>> like check [ "$USER" = "root" ] and you don't feel like going first
>> through loggin as you or your root account, then su'ing to be root
>> because it can completely screw up X-windows apps.
>
>
> Then you don't FEEL LIKE putting the effort into security.
>
> Peter stated it shouldn't be done, and you don't have to do it that way.
> Well he's right. He did not state that you can't do it.
If I need to blow hours a month building and maintaining additional
local root accounts on all the machines I work with, then I'm not doing
my job. I've got *MUCH* better things to do, or can use the time instead
for relatively frequent updates of the sitewide root passwords or other
security managementn tasks.
Moreover, when I have to deal with a new hire as a systems geek, I'd
have to push *their* account to all the new machines, and change all the
old account lists when they leave, even on the machines that have to not
run network services for security reasons. If my boss didn't slap me in
the head, *I'd* slap me in the head. It's vastly easier to change the
root password sitewide or network wide.
Now, if you have a site policy that the root account is locked and there
is only one local root-level account, great. But then you have to deal
with the "housekeeping accidentally pulled the power cord, and I need
the root password to run fsck or the BIOS password to edit the boot
parameters and use 'init=/bin/sh'".
It's all trade-offs in flexibility vs. power. The absolute "thou shalt
not log into console as root" is not unreasonable as a guideline, but
it's not a *rule*.
> I don't think many home users have their security set to Paranoid
> though, if you turn it down to High or Medium you should be able to
> login as root.
>
> I can't help you with how to change it though. In the past year I've
> gone through RH7.2, MDK9.0, Deb3.0r1, and Slackware9.0, and it's a real
> guessing game trying to figure out which tools exist for which distro,
> and I don't know how to set that in the config files.
>
> Michael C.
Amen, for this and lots of other services. I'm running easily 12
different OS's this month, and sympathize with your pain.
- Next message: Peter T. Breuer: "Re: can't login as root"
- Previous message: Peter T. Breuer: "Re: can't login as root"
- In reply to: Michael C.: "Re: can't login as root"
- Next in thread: Peter T. Breuer: "Re: can't login as root"
- Reply: Peter T. Breuer: "Re: can't login as root"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
