Problem with second user with uid 0?
Hi, are there any security (or other) problems when having a second user with uid 0? We would like to mainain a user "rootid" which has uid 0 and should be used for normal users logging in as root when the admin (me) is e.g. on holidays and sth. fails and needs to be repaired. For this, we have sealed envelopes with the root passwords which some users can open to get the password (the boss wants it like that). To avoid changing "my" root password afterwards, users should get the password for "rootid" and work with that account. After my return, I would just have to change the rootid password and could still work with my normal root password. "sudo" etc. is not a real solution, because users might need to login during boot when fsck fails. And then you need a root password and no sudo etc. Are there any problem with such a setup? Of course the rootid account must be protected the same way the root account is. In a first test, I could do anything with the rootid user, but I'm not sure if there are any security traps that I don't recognize... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Thursday 10 March 2005 4:52 am, Frank Steiner wrote:
Hi,
are there any security (or other) problems when having a second user with uid 0? We would like to mainain a user "rootid" which has uid 0 and should be used for normal users logging in as root when the admin (me) is e.g. on holidays and sth. fails and needs to be repaired. For this, we have sealed envelopes with the root passwords which some users can open to get the password (the boss wants it like that).
<snip> IANAL and not as knowledgable as others on the list, but you might consider the "Administrators" setup where they aren't logged into the computer as a regular user. In other words, the Administrator account really isn't at least under the same user name an account on the computer. That might slow down any uninvited boost to the "normal" user rights.. Seriously tho, Something important to consider : you need to have a serious chat w/ the boss.. perhaps a meeting setup and scheduled to apprise him/her/them w/ the actual things a "root" user can do that might actually not be what the company would want to allow. It appears what your boss wants is not to be bothered during times you aren't around w/ any fiddley little things that go wrong w the computers, he just wants them to keep working... And no doubt hasn't considered any other ramifications. Industrial espionage, or just plain boredom or curiosity can lead to people "just looking" at information they do not have any need to know. As others have said, a root user has access to all information on your network systems. This might and can eventually lead to legal problems for your boss and the company depending on where mischief or curiosity leads, and what legal or fiduciary responsibilities the company may have. Those get very very expensive and you do not want to be associated in any way w/ setting up a system that might lead to such things w/o absolutely making certain your immediate superior(s) are fully apprised of the dangers. After all, your future is at stake as well as theirs. Imagine attempting to get another IT job if some fiasco happened to a company where you were the IT dept. Or the head of same... It would be bad enough if it didn't get publicized. I doubt there would be any future in the industry should anything untoward happen and you have not protected yourself by apprising those who should know of the potential for minor ( he types "rm -rf .*" in some user directory ) or major... (think the current fuss over info released about Paris Hilton's address book and translate it to , oh, release of people's info by a doctor, lawyer, hospital etc... ) -- j I'm putting on the B-mer Brothers Would you mind putting on this grass skirt?
Hi, If your system boots with an initrd (check this in /boot/grub/menu.lst) a "new" root account does not work. Your college will need the password stored in the initrd. ( If fsck checkes / ) Enno On Thursday 10 March 2005 10:52, Frank Steiner wrote:
Hi,
are there any security (or other) problems when having a second user with uid 0? We would like to mainain a user "rootid" which has uid 0 and should be used for normal users logging in as root when the admin (me) is e.g. on holidays and sth. fails and needs to be repaired. For this, we have sealed envelopes with the root passwords which some users can open to get the password (the boss wants it like that).
To avoid changing "my" root password afterwards, users should get the password for "rootid" and work with that account. After my return, I would just have to change the rootid password and could still work with my normal root password. "sudo" etc. is not a real solution, because users might need to login during boot when fsck fails. And then you need a root password and no sudo etc.
Are there any problem with such a setup? Of course the rootid account must be protected the same way the root account is.
In a first test, I could do anything with the rootid user, but I'm not sure if there are any security traps that I don't recognize...
cu, Frank
-- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
-- Groeten van Enno Oosterhuis e.oosterhuis@ewi.utwente.nl
On Thursday 10 March 2005 13.57, E. Oosterhuis wrote:
Hi,
If your system boots with an initrd (check this in /boot/grub/menu.lst) a "new" root account does not work. Your college will need the password stored in the initrd. ( If fsck checkes / )
Enno
On Thursday 10 March 2005 10:52, Frank Steiner wrote:
Hi,
are there any security (or other) problems when having a second user with uid 0? We would like to mainain a user "rootid" which has uid 0 and should be used for normal users logging in as root when the admin (me) is e.g. on holidays and sth. fails and needs to be repaired. For this, we have sealed envelopes with the root passwords which some users can open to get the password (the boss wants it like that).
To avoid changing "my" root password afterwards, users should get the password for "rootid" and work with that account. After my return, I would just have to change the rootid password and could still work with my normal root password. "sudo" etc. is not a real solution, because users might need to login during boot when fsck fails. And then you need a root password and no sudo etc.
Are there any problem with such a setup? Of course the rootid account must be protected the same way the root account is.
In a first test, I could do anything with the rootid user, but I'm not sure if there are any security traps that I don't recognize...
cu, Frank
-- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
-- Groeten van
Enno Oosterhuis
e.oosterhuis@ewi.utwente.nl
Wont the "second" root be able to reset ordinary roots password? Or add a "backdoor" on the system? Malicious code can easily be installed once logged in as uid 0. "I'll just up my pesonal powers a wee bit" is always the most dangerous thing. -- /Rikard --------------------------------------------------------------- Rikard Johnels email : rikjoh@norweb.se Web : http://www.rikjoh.com/users/rikjoh Mob : +46 735 05 51 01 PGP : 0x461CEE56 ---------------------------------------------------------------
Rikard Johnels wrote
Wont the "second" root be able to reset ordinary roots password? Or add a "backdoor" on the system? Malicious code can easily be installed once logged in as uid 0. "I'll just up my pesonal powers a wee bit" is always the most dangerous thing.
Of course, you are right! But I wrote that in my answer to Martin Wilde, we do trust our users in a certain way. They have physical access to the servers, so they could easily break in whenever they wanted. Currently, they get the real root password from opening the envelope, and then I have to change my root passwords which I don't want to do too often (it's not that easy to find easy to remember, easy to type and still hard to break passwords :-)). So with the "rootid", the only difference is that I don't have to change "my" root password, but only "their" root password. cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
Hi Enno, E. Oosterhuis wrote
Hi,
If your system boots with an initrd (check this in /boot/grub/menu.lst) a "new" root account does not work. Your college will need the password stored in the initrd. ( If fsck checkes / )
I'm not sure about this. We do have initrds on some systems, for loading the scsi and fs modules needed to access the root fs. However, the checking of the root fs is done in /etc/init.d/boot.* scripts, when the root fs is already mounted ro, so the usual /etc/passwd should be used already. I' not aware of a setup where the fsck is done from within the initrd, but maybe that happens on systems other than SuSE? They only check via the boot scripts after loading kernel/initrd... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
I'm in a similar situation of having to leave root passwords in "a secure place" incase I am not around. :( Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server. The drawback to this is that you have to leave the server bootable from CD :(, which is in itself a security hole. On a positive note though, people don't just have the root password "on tap" and are hopefully less inclined to obtain the rescue disk and boot up as root "just for the hell of it". It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last week during a routine outage...
-----Original Message----- From: Frank Steiner [mailto:fsteiner-mail@bio.ifi.lmu.de] Sent: Thursday, 10 March 2005 10:53 p.m. To: SuSE Securitylist Subject: [suse-security] Problem with second user with uid 0?
Hi,
are there any security (or other) problems when having a second user with uid 0? We would like to mainain a user "rootid" which has uid 0 and should be used for normal users logging in as root when the admin (me) is e.g. on holidays and sth. fails and needs to be repaired. For this, we have sealed envelopes with the root passwords which some users can open to get the password (the boss wants it like that).
To avoid changing "my" root password afterwards, users should get the password for "rootid" and work with that account. After my return, I would just have to change the rootid password and could still work with my normal root password. "sudo" etc. is not a real solution, because users might need to login during boot when fsck fails. And then you need a root password and no sudo etc.
Are there any problem with such a setup? Of course the rootid account must be protected the same way the root account is.
In a first test, I could do anything with the rootid user, but I'm not sure if there are any security traps that I don't recognize...
cu, Frank
-- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Just an additional hint for the security. Each access to the console is a security risk. Not only the boot from CD. You can e.g. boot with the option "init=/bin/bash" if it's not restricted. => logged in with a root shell => remount / "read write" => ( do not forget to "sync" manually after changes to recover a password.) ... I would prefer to have a one time used password placed in a signed envelope. If it's broken after an emergency action you have to choose a new password. But you have to find a secure place for this envelope also... Best regards, Christian Mike Tierney wrote:
I'm in a similar situation of having to leave root passwords in "a secure place" incase I am not around. :(
Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server.
The drawback to this is that you have to leave the server bootable from CD :(, which is in itself a security hole. On a positive note though, people don't just have the root password "on tap" and are hopefully less inclined to obtain the rescue disk and boot up as root "just for the hell of it".
It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last week during a routine outage...
Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server.
The drawback to this is that you have to leave the server bootable from CD :(, which is in itself a security hole. On a positive note though, people don't just have the root password "on tap" and are hopefully less inclined to obtain the rescue disk and boot up as root "just for the hell of it".
It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last week during a routine outage...
But, in this case, you can leave the boot cd to your boss, and protect either the BIOS and the Bootloader with a password that only you and / or boss know. If somebody needs to run a fsck, he will need to enter the BIOS pwd and the booloader password. -- Saludos, miguel
In an ideal world of course you would: 1) Use only server cases with padlocks and fasten those with steel cable to rings set into the walls or floor. 2) Password the BIOS 3) Set the server to not boot from CDROM by default 4) Encrypt the hard drives via a loopback device 5) Maybe abandon using the SUSE kernal and use something ultra secure like LIDS :) But seriously, you have to draw the line somewhere!! If anyone is *REALLY* determined they can 1) Cut the padlock 2) Pop the case and clear the BIOS password via jumpers 3) Change the BIOS back to booting from CDROM and pop in a boot disk 4) Not sure how they'd deal with the encrypted disks! Maybe get a job as a cleaner and install a keystroke logger on the keyboard a few weeks beforehand...? So all of a sudden leaving the root password in a sealed envelope that's stored in a locked filing cabinent doesn't sound so bad after all!!!!
-----Original Message----- From: miguel gmail [mailto:miguel.listas@gmail.com] Sent: Friday, 11 March 2005 11:23 p.m. Cc: SuSE Securitylist Subject: Re: [suse-security] Problem with second user with uid 0?
Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server.
The drawback to this is that you have to leave the server bootable from CD :(, which is in itself a security hole. On a positive note though, people don't just have the root password "on tap" and are hopefully less inclined to obtain the rescue disk and boot up as root "just for the hell of it".
It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last week during a routine outage...
But, in this case, you can leave the boot cd to your boss, and protect either the BIOS and the Bootloader with a password that only you and / or boss know. If somebody needs to run a fsck, he will need to enter the BIOS pwd and the booloader password.
-- Saludos, miguel
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
security is not really the issue here, otherwise you would just change the password when you get back (which should be done regularly anyway), its more the convenience of not having to do so. Your best bet is to take a test pc and try set up 2 uid 0's and run whatever you think might need to be run. Nick On Friday 11 March 2005 13:22, Mike Tierney wrote: In an ideal world of course you would: 1) Use only server cases with padlocks and fasten those with steel cable to rings set into the walls or floor. 2) Password the BIOS 3) Set the server to not boot from CDROM by default 4) Encrypt the hard drives via a loopback device 5) Maybe abandon using the SUSE kernal and use something ultra secure like LIDS :) But seriously, you have to draw the line somewhere!! If anyone is *REALLY* determined they can 1) Cut the padlock 2) Pop the case and clear the BIOS password via jumpers 3) Change the BIOS back to booting from CDROM and pop in a boot disk 4) Not sure how they'd deal with the encrypted disks! Maybe get a job as a cleaner and install a keystroke logger on the keyboard a few weeks beforehand...? So all of a sudden leaving the root password in a sealed envelope that's stored in a locked filing cabinent doesn't sound so bad after all!!!!
-----Original Message----- From: miguel gmail [mailto:miguel.listas@gmail.com] Sent: Friday, 11 March 2005 11:23 p.m. Cc: SuSE Securitylist Subject: Re: [suse-security] Problem with second user with uid 0?
Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server.
The drawback to this is that you have to leave the server bootable from CD :(, which is in itself a security hole. On a positive note though, people don't just have the root password "on tap" and are hopefully less inclined to obtain the rescue disk and boot up as root "just for the hell of it".
It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last week during a routine outage...
But, in this case, you can leave the boot cd to your boss, and protect either the BIOS and the Bootloader with a password that only you and / or boss know. If somebody needs to run a fsck, he will need to enter the BIOS pwd and the booloader password.
-- Saludos, miguel
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Friday 11 March 2005 10:57, nick wrote: In my paranoid/humble opinion, the root account renders a weak spot, as long as security concerns. Having one weak spot is BAD, having two... you get the point. In this specific case I have came out with this simple security model. 1) The BIOS password should be set , and known only by the boss or revealed with its prior authorization; 2) There should be a Rescue CD locked down in a secure locker; 3) Day-to-day administrative work should be controlled using sudo; 4) Audit everything The Disaster Plan process would be: ALERT: HOST DeltaFox CRASHED ! if ( CALL host Admin ) { Execute Disaster Recovery Procedure } else { CALL Boss CALL Second host Admin Boss unlocks BIOS Second host Admin Executes Recovery Procedure } BIOS password should be considered an OTP, specially in the case the boss reveals it to the Second Host Admin. HTH, HLM
security is not really the issue here, otherwise you would just change the password when you get back (which should be done regularly anyway), its more the convenience of not having to do so. Your best bet is to take a test pc and try set up 2 uid 0's and run whatever you think might need to be run.
Nick
On Friday 11 March 2005 13:22, Mike Tierney wrote: In an ideal world of course you would: 1) Use only server cases with padlocks and fasten those with steel cable to rings set into the walls or floor. 2) Password the BIOS 3) Set the server to not boot from CDROM by default 4) Encrypt the hard drives via a loopback device 5) Maybe abandon using the SUSE kernal and use something ultra secure like LIDS :)
But seriously, you have to draw the line somewhere!!
If anyone is *REALLY* determined they can
1) Cut the padlock 2) Pop the case and clear the BIOS password via jumpers 3) Change the BIOS back to booting from CDROM and pop in a boot disk 4) Not sure how they'd deal with the encrypted disks! Maybe get a job as a cleaner and install a keystroke logger on the keyboard a few weeks beforehand...?
So all of a sudden leaving the root password in a sealed envelope that's stored in a locked filing cabinent doesn't sound so bad after all!!!!
-----Original Message----- From: miguel gmail [mailto:miguel.listas@gmail.com] Sent: Friday, 11 March 2005 11:23 p.m. Cc: SuSE Securitylist Subject: Re: [suse-security] Problem with second user with uid 0?
Though in the fsck case there is an alternative I have just thought of,
but
the solution may be WORSE than the problem! If you want people to be
able to
do a fsck in an emergency, then you could always leave a "Rescue CD"
with
your boss... Then if anyone needs to actually do a fsck on a crashed
server
they can use the rescue disk to boot up and fsck the filesystem in
question,
and then reboot the server.
The drawback to this is that you have to leave the server bootable from
CD
:(, which is in itself a security hole. On a positive note though,
people
don't just have the root password "on tap" and are hopefully less
inclined
to obtain the rescue disk and boot up as root "just for the hell of it".
It's always good to have rescue disks handy anyway, just incase the root/boot file system gets corrupted/damaged. Like I experienced last
week
during a routine outage...
But, in this case, you can leave the boot cd to your boss, and protect either the BIOS and the Bootloader with a password that only you and / or boss know. If somebody needs to run a fsck, he will need to enter the BIOS pwd and the booloader password.
-- Saludos, miguel
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Mike Tierney wrote
If anyone is *REALLY* determined they can
1) Cut the padlock 2) Pop the case and clear the BIOS password via jumpers
Right. So whenever a user has physcial access to the hardware, you can't do much to prevent him from hacking into the system. And a user who should recover a broken system when I'm off, should have access to the server he needs to recover, so... I think the question here is: How easy should it be for someone to get root access? If users know the root password by default, they tend to use it from time to time "to do a little fix or install a little program because the admin has already gone home...", and that's what we don't want. In case sth. breaks while I'm not in the office, a pre-selected user opens a sealed envelope. I see this when I'm back and change the password again to avoid this user doing "a little fix or..." :-) Because this user must have a key to the server room, I must trust him that he does not open the server and resets the bios to break in. And if I trust him this way, I can also trust him that he does not install a backdoor after opening the envelope and working as root to fix the server. That's the deal. Nothing more. And all I want to reach is to give this user a different root password than my usual root password, so that I don't have to change mine after the envelope was opened.
3) Change the BIOS back to booting from CDROM and pop in a boot disk 4) Not sure how they'd deal with the encrypted disks! Maybe get a job as a cleaner and install a keystroke logger on the keyboard a few weeks beforehand...?
So all of a sudden leaving the root password in a sealed envelope that's stored in a locked filing cabinent doesn't sound so bad after all!!!!
Especially not for a chair with 10 people where we all know each other very well and everyone knows where to get the key to enter the server room :-) -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
miguel gmail wrote
But, in this case, you can leave the boot cd to your boss, and protect either the BIOS and the Bootloader with a password that only you and / or boss know. If somebody needs to run a fsck, he will need to enter the BIOS pwd and the booloader password.
Anyway, in which way would this be more secure than giving the user the password? Booting from a CD to perform the fsck, he can enter a new encrypted string to /etc/shadow and has the root password after rebooting. So this is the same risk like giving the user the root password: He can hack your system. But as I said before, I must trust someone who is supposed to care about the system if I'm not there. Otherwise, no one but me can ever maintain anything... -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Fri, 11 Mar, 2005 at 23:52:39 +0100, Frank Steiner wrote: <snip>
Anyway, in which way would this be more secure than giving the user the password? Booting from a CD to perform the fsck, he can enter a new encrypted string to /etc/shadow and has the root password after rebooting.
<snip> So why don't you simply do that? Right before you leave, you edit /etc/shadow and - move 'your' encrypted string off of the system - enter a different string And when you return; Move 'your' string back into /etc/shadow. HTH /Jon -- YMMV
Jon Clausen wrote
So why don't you simply do that?
Right before you leave, you edit /etc/shadow and
- move 'your' encrypted string off of the system - enter a different string
And when you return;
Move 'your' string back into /etc/shadow.
Yes, good idea, and very simple :-) Thanks! -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Saturday 12 March 2005 22:48, Frank Steiner wrote:
Jon Clausen wrote
So why don't you simply do that?
Right before you leave, you edit /etc/shadow and
- move 'your' encrypted string off of the system - enter a different string
And when you return;
Move 'your' string back into /etc/shadow.
Yes, good idea, and very simple :-) Thanks!
There's even a tool to simplify these step: passwd.... Paul
Hi Mike, Mike Tierney wrote
I'm in a similar situation of having to leave root passwords in "a secure place" incase I am not around. :(
Though in the fsck case there is an alternative I have just thought of, but the solution may be WORSE than the problem! If you want people to be able to do a fsck in an emergency, then you could always leave a "Rescue CD" with your boss... Then if anyone needs to actually do a fsck on a crashed server they can use the rescue disk to boot up and fsck the filesystem in question, and then reboot the server.
a good solution for simple PCs, but we also run some IBM pSeries for which the users first would have to attach the SCSI-CDROM to the right controller, then enter the pSeries bios via a Hardware Management Console and chose the boot order in a way very very different and more complicated from a PC bios. In this case, I really would prefer to let them know the root password :-) -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
participants (11)
-
Christian Volkmann -
E. Oosterhuis -
Frank Steiner -
Helio Leonardo Mota -
jfweber＠bellsouth.net -
Jon Clausen -
miguel gmail -
Mike Tierney -
nick -
Paul van Eldijk -
Rikard Johnels