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



## zeissoctopus (Jul 27, 2013)

May you share your opinion, thank you!


----------



## zspider (Jul 27, 2013)

No, I just leave toor alone.


----------



## kpa (Jul 27, 2013)

I do use toor to keep the real root user as unmodified as possible. For example my su(1) command is an alias to `su toor`.


----------



## fonz (Jul 27, 2013)

No, I don't use it. In fact, I often remove toor entirely.


----------



## ShelLuser (Jul 27, 2013)

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.


----------



## kpa (Jul 27, 2013)

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.


----------



## fonz (Jul 27, 2013)

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.


----------



## graudeejs (Jul 27, 2013)

I've set /bin/csh as shell for toor, while I use my favorite shells/mksh for root. If things go sideways I can always log in as root with toor.


----------



## DutchDaemon (Jul 27, 2013)

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..


----------



## ShelLuser (Jul 28, 2013)

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).


----------



## kpa (Jul 28, 2013)

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.


----------



## graudeejs (Jul 28, 2013)

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.


----------



## kpa (Jul 28, 2013)

It's not a very big if  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.


----------



## jmccue (Jul 28, 2013)

I never use toor, in fact I like csh(1).


----------



## neelwebs (Jul 29, 2013)

jmccue said:
			
		

> I never use toor, in fact I like csh(1).



I'm same with you.


----------



## srobert (Jul 29, 2013)

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.


----------



## throAU (Jul 29, 2013)

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`.


----------



## Dies_Irae (Jul 29, 2013)

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:

```
set myshell='/usr/local/bin/myshell'
if ( -x $myshell ) then
  $myshell
endif
```

without the need to create any additional user(s).


----------



## mortoxa (Jul 31, 2013)

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:


```
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.)


----------



## DutchDaemon (Jul 31, 2013)

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.


----------

