Root on my debian?

When I use su to get root, and then I cd ~

I am not on the /root, when I ls it shows me a Desktop file and some hidden files like .bashrc, but nothing else.

root@debian:~# ls -a
. .. .adobe .bash_history .bashrc .cache .config Desktop .gnome2 .gnome2_private .local .macromedia .mozilla .profile .vim .viminfo

to go to the real /root I have to cd / from here.

I thought that there were no ../ from /root, so what is this ~ ?

edit 2 :

xxxx@debian:~$ ls
Desktop Documents Downloads Music Pictures Public Templates Videos
xxxx@debian:~$ su
Password:
root@debian:/home/xxxx# cd
root@debian:~# ls
Desktop
root@debian:~# pwd
/root
root@debian:~# cd /
root@debian:/# ls
bin boot dev etc home initrd.img lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz
root@debian:/# pwd
/

asked Dec 20, 2015 at 18:00

You are mistaking two things that have similar names.

root — is also called / — it’s the starting point of your disc. If you imagine your filesystem laid out as a tree(in mathematical sense), you will see clearly why it’s called a root — it does not have an ancestor, only children.

However, /root is whole different thing. You can see the name differs — very little, only / at the beginning, but that’s what changes meaning dramatically. /root is a directory called root which you can find in /. So, if you do:

answered Dec 20, 2015 at 18:36

6 gold badges30 silver badges54 bronze badges

answered Dec 20, 2015 at 18:06

14 gold badges132 silver badges255 bronze badges

answered Dec 20, 2015 at 18:05

1 gold badge12 silver badges20 bronze badges

To know where you are in the directory tree, you have to type:

pwd

cd /

answered Dec 20, 2015 at 18:14

1 gold badge5 silver badges14 bronze badges

Security is always about making trade-offs. Just like the proverbial server which is in a safe, unplugged, at the bottom of the ocean, root would be most secure if there were no way to access it at all.

But, sudo-for-unrestricted-root does address another security problem: manageability of root passwords. At many organizations, these tend to be passed around like candy, written on whiteboards, and left the same forever. That leaves a big vulnerability, since revoking or changing access becomes a big production number. Even keeping track of what machine has what password is a challenge — let alone tracking who knows which one.

Remember that most «cyber-crime» comes from within. With the root password situation described, it’s hard to track down who did what — something sudo with remote logging deals with pretty well.

On your home system, I think it’s really more a matter of the convenience of not having to remember two passwords. It’s probable that many people were simply setting them to be the same — or worse, setting them to be the same initially and then letting them get out of sync, leaving the root password to rot.

Using passwords at all for SSH is dangerous, since password-sniffing trojaned ssh daemons are put into place in something like 90% of the real-world system compromises I’ve seen. It’s much better to use SSH keys, and this can be a workable system for remote root access as well.

But the problem there is now you’ve moved from password management to key management, and ssh keys aren’t really very manageable. There’s no way of restricting copies, and if someone does make a copy, they have all the attempts they want to brute-force the passphrase. You can make policy saying that keys must be stored on removable devices and only mounted when needed, but there’s no way of enforcing that — and now you’ve introduced the possibility of a removable device getting lost or stolen.