Do you use "toor" instead of "root"?

Never touched it, I don't think it has any advantages for me. In fact I always disable the account because having another root user around is basically an extra risk in my opinion.

Although it did take getting used to I actually came to appreciate the C Shell quite a bit, sometimes it's even more efficient; like when redirecting both stdout and stderr for example; echo > logfile 2>&1 in bash or ksh and echo >& logfile in csh.

Of course there are also numerous of examples where it's actually a bit harder to use.
 
ShelLuser said:
Never touched it, I don't think it has any advantages for me. In fact I always disable the account because having another root user around is basically an extra risk in my opinion.

Could you elaborate a bit why the additional account is an extra risk in your opinion? If you have the same login limitations for both superuser accounts there is really no difference to using either one from the security standpoint. Both have the same powers so gaining unauthorized access to either one means full compromise anyway.
 
kpa said:
Could you elaborate a bit why the additional account is an extra risk in your opinion?
Please forgive me for breaking in, but I suspect he means it's another account with a password that can be cracked. It may pose the same threat as root once compromised, but it's an additional point of attack.
 
The other way around for me: root unmodified, toor with my shell from ports; I also have an unmodified wheel account, whereas my own login also has a shell from ports..
 
fonz said:
Please forgive me for breaking in, but I suspect he means it's another account with a password that can be cracked.
Though this rude interruption is almost unforgivable you're still absolutely right ;)

fonz said:
It may pose the same threat as root once compromised, but it's an additional point of attack.
Indeed, also because it's a well known "backdoor" (to a certain extent of course). And basically something you always need to keep in mind whenever you're setting up stuff such as intrusion detection (or logfile diagnostics) because by default such software will focus their attention on root and not so much toor.

Unless of course you're using stuff which provides explicit (Free)BSD support (I have no idea how this is handled on NetBSD and/or OpenBSD, but I assume it's the same).
 
That's why you have the restrictions on who can even try a root/toor login. You never allow them directly over ssh(1). You have a very limited set of user accounts in the wheel group. I just don't see how toor account is a "known backdoor" when it's only found on BSD systems and if you do your set up properly it is never more vulnerable to attacks than the root account.
 
kpa said:
That's why you have the restrictions on who can even try a root/toor login. You never allow them directly over ssh(1). You have a very limited set of user accounts in the wheel group. I just don't see how toor account is a "known backdoor" when it's only found on BSD systems and if you do your set up properly it is never more vulnerable to attacks than the root account.

Because there is if in your last sentence.
 
It's not a very big if :p It's in fact a tiny one. We are talking about a user account that is not enabled by default and if you know that you need/want to enable it you are one of those people who know how to secure it as well.
 
Yes, I use su toor to administer my laptop because I prefer bash over the default shell. Previously, I hadn't experienced any problems using sudo su and setting root's shell to bash, but experienced users in the forum advised against that and I trust their judgement.
 
Nope.

I leave root alone (don't log in via it at least, and don't modify its profile at all), never use toor either.

I use SSH public key login, and a 32 character random password for sudo.
 
Never used it, and I can't see how this coud be of any use (at least for me).

I just add every authorized user (me) to the wheel group and then use su(1) to become root, but I'm slowly replacing it with sudo (it's hard to get rid of bad habits).

I've never changed the default root shell, and I use (t)csh even for my regular user, so usually I don't install any additional shell, but if in an hypothetical future I will decide to use another shell for root, probably I will only append these lines to .cshrc:
Code:
set myshell='/usr/local/bin/myshell'
if ( -x $myshell ) then
  $myshell
endif

without the need to create any additional user(s).
 
I used to use the toor account, with bash, until I started to get some puzzling errors when updating ports.

There was definitely a problem updating lang/perl5.14 and also graphics/libGL I think. Just to check my memory I temporarily changed the root shell to bash and re-compiled lang/perl5.14. It failed with the following error:

Code:
LD_LIBRARY_PATH=/usr/ports/lang/perl5.14/work/perl-5.14.4  ./perl -f -Ilib pod/buildtoc --build-toc -q
Unknown option: q
pod/buildtoc: Usage: pod/buildtoc [--verbose] [--showfiles] --build-all | --build-dmake | --build-manifest | --build-nmake | --build-perlpod | --build-podmak | --build-toc | --build-unix | --build-vms
*** [pod/perltoc.pod] Error code 255

Stop in /usr/ports/lang/perl5.14/work/perl-5.14.4.
*** [do-build] Error code 1

Stop in /usr/ports/lang/perl5.14.
*** [build] Error code 1

Stop in /usr/ports/lang/perl5.14.

===>>> make failed for lang/perl5.14
===>>> Aborting update

===>>> Killing background jobs
Terminated

===>>> You can restart from the point of failure with this command line:
       portmaster <flags> lang/perl5.14 

===>>> Exiting

Then I changed back to the csh and it compiles and re-installs with no problems at all.

So after I realised that using bash on the toor account was causing this trouble with ports, I decided it just wasn't worth the hassle and determined to learn to love the csh and just use the root account. After all there is little use for me in having a superuser account that can only do some jobs.

I reckon this is also another good reason to heed the advice to never change the root shell to anything but csh. (If anyone really needs another reason.) :)
 
Sounds like the typical "Oops, forgot to recursively upgrade gettext and now bash is b0rked" problem, not anything to do with using toor itself. Which is exactly why you leave root alone. For those cases.
 
Back
Top