Случайно перемещенные каталоги под корнем
Я случайно выполнил эту команду
sudo mv /* /applications/minced/
вместо
sudo mv ./* /applications/minced/
Это - все, что это оставляют в корневом каталоге
$ /
applications/ dev/ proc/ run/ sys/ tmp/
У меня все еще есть активное соединение SSH к серверу. Я попытался звонить mv, sudo и chmod... непосредственно от /applications/minced/bin/ или /applications/minced/usr/bin/, но ничто не работает, хотя я могу определить местоположение их там использующий автозавершение пути.
$ /applications/minced/bin/ls
-bash: /applications/minced/bin/ls: No such file or directory
Я читал, Возвращаются, перемещая корневой каталог рекурсивно, но монтируя, что система под LiveCD не является опцией для меня, так как это - VPS, не реальная машина. Какие-либо идеи?
Обновление
Я выяснил, что это происходит из-за проблем связи библиотеки, таким образом, я сделал это
$ 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/* /
Очевидно, я столкнулся с проблемами разрешения. Вызов sudo с компоновщиком бросает эту ошибку
$ /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?
Как предложил Barafu Albino, я попытался звонить su с busybox (.../bin/busybox su -), но это бросает su: must be suid to work properly. Я предполагаю, что это происходит потому что su не может расположиться /etc/passwd и /etc/shadow. Кажется, что я завинтил систему полностью.
3 ответа
Ваши приложения не могут работать, потому что они хотят найти библиотеки, и это неуместно также. Попытайтесь использовать busybox непосредственно.
bin/busybox ls
должен работать ls и так далее.
Позволяет делают другой подход. Я предполагаю, что Вы не знаете реального пароля root. Вот список библиотек, в которых нуждается sudo:
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)
Вот список файлов в sudo пакете (только соответствующие):
/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
Попытка движущиеся библиотеки к двоичному файлу, в ту же папку. Может быть это, будет работать. su имеет меньше зависимостей, но требует для знания реального пароля root.
Я просто сталкиваюсь с этой проблемой точно как это сообщение. Я использую сервер Ubuntu, который имеет отключенного пользователя root и использует sudo, чтобы сделать корневые команды. таким образом, я не могу войти в систему с пользователем root случайно, единственный путь ко мне в экземпляре делает sudo работы. к сожалению, часы передали, я перестал работать, очень жаль.
И для пользователей, которые могут войти в систему с корнем, я предполагаю Вас, парни забыли упоминать иначе, который может быть намного легче: busybox sulogin