7

I've accidentally run this command

sudo mv /* /applications/minced/

instead of

sudo mv ./* /applications/minced/

This is all that's left in the root directory

$ /
applications/ dev/          proc/         run/          sys/          tmp/       

I still have an active ssh connection to the server. I've tried calling mv, sudo and chmod... directly from /applications/minced/bin/ or /applications/minced/usr/bin/, but nothing works, though I can locate them there using path autocompletion.

$ /applications/minced/bin/ls
-bash: /applications/minced/bin/ls: No such file or directory

I've read Revert moving root directory recursively, but mounting the system under LiveCD is not an option for me since it's a VPS, not a physical machine. Any ideas?

Update

I figured out this is due to library linkage problems, so I did this

$ export LD_LIBRARY_PATH=/applications/minced/lib/x86_64-linux-gnu/
$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/bin/mv /applications/minced/* /

Obviously I ran into permission problems. Calling sudo with the linker throws this error

$ /applications/minced/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /applications/minced/usr/bin/sudo ...
sudo: effective uid is not 0, is /applications/minced/usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

As suggested by Barafu Albino, I've tried calling su with busybox (.../bin/busybox su -), but it throws su: must be suid to work properly. I guess this happens because su can't locate /etc/passwd and /etc/shadow. Seems like I've screwed up the system completely.

3 Answers3

10

Your applications can not run because they want to find libraries and those are misplaced too. Try using busybox directly.

bin/busybox ls

should work as ls and so on.

heemayl
  • 93,925
4

Lets do another approach. I assume you do not know real root password. Here is a list of libraries that sudo needs:

linux-vdso.so.1 =>  (0x00007ffea6be9000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fbbad17b000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fbbacf78000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbbacd74000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbbac9aa000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbbac73d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbbad5c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbbac51f000)

Here is a list of files in sudo package (only relevant ones):

/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/sudo.service
/usr
/usr/lib
/usr/lib/sudo
/usr/lib/sudo/system_group.so
/usr/lib/sudo/sudo_noexec.so
/usr/lib/sudo/sudoers.so
/usr/lib/sudo/group_file.so
/usr/lib/sudo/sesh
/usr/bin
/usr/bin/sudoreplay
/usr/bin/sudo

Try moving libraries to the binary, into the same folder. May be it will work. su has less dependencies, but requires to know real root password.

0

I just run into this problem exactly like this post. I'm using an Ubuntu server which has a disabled root user and is using sudo to do the root commands. so I can't log in with root user by any chance, the only way for me in the instance is making the sudo works. unfortunately, hours passed, I failed, that's too bad.

And for users who can log in with the root, I suppose you guys forgot to mention another way which may be much easier: busybox sulogin