Ubuntu 12.04 LTS: dpkg-statoverride: błąd: Nadpisanie dla "/bin/su" już istnieje, przerywanie.

[kitek]

Cześć. Jakiś czas temu, w celach testowych, zmieniłem właściciela dla /bin/su. Domyślnie konto administratora (root) jest w systemie Ubuntu zablokowane. Niemniej, właściciel wygląda w ten sposób:

Kod: Zaznacz cały

[~]$ ls -al /bin/su
-rwsr-xr-x 1 root root 35220 Jul 26 18:07 /bin/su

W moim przypadku, po wprowadzonych zmianach (nietsety nie jestem w stanie przypomnieć sobie sposobu z którego skorzystałem), sytuacja przedstawia się następująco:

Kod: Zaznacz cały

[~]$ ls -al /bin/su
-rwsr-x--- 1 root adm 31116 Dec 13  2012 /bin/su

Chciałbym przywrócić domyślne ustawienie, czyli: root:root, ale występują problemy z którymi nie mam pojecia w jaki sposób sobie poradzić. W celu zmiany właściciela, wykorzystuję polecenie dpkg-statoverride, ale w wyniku działania otrzymuję komunikat o błędzie:

Kod: Zaznacz cały

[~]$ sudo dpkg-statoverride --update --add root root 4750 /bin/su
dpkg-statoverride: błąd: Nadpisanie dla "/bin/su" już istnieje, przerywanie.

Te same informacje można znaleźć w pliku /var/lib/dpkg/statoverride, który zawiera, między innymi,:

Kod: Zaznacz cały

[~]$ cat /var/lib/dpkg/statoverride (to samo, co: dpkg-statoverride --list)
[...]
root adm 4750 /bin/su

W związku z powyższym, chciałbym poprosić o radę w jaki sposób mogę przywrócić domyślne ustawienie? Myślałem o skorzystaniu z polecenia dpkg-statoverride --remove ..., ale nie wiem, czy jest to odpowiednie podejście. Być może wystarczy, tylko chown(1) albo ręczna edycja pliku /var/lib/dpkg/statoverride i zmiana root adm na root root?

Jest to maszyna testowa, ale przygotowuję się do aktualizacji, poza tym chciałbym rozwiązać ten problem, aby w przyszłości wiedzieć, co należy robić w podobnej sytuacji (np. pomagając komuś).

Dzięki.

[marcin1982]

Sprawdziłem - przywraca oryginalne artybuty:

Kod: Zaznacz cały

apt-get install --reinstall login

[saturno]

poza tym chciałbym rozwiązać ten problem, aby w przyszłości wiedzieć, co należy robić w podobnej sytuacji

Aby w przyszłości nie mieć potrzeby rozwiązywać podobnych kłopotów rób kopie zapasowe modyfikowanych plików.

[kitek]

Cześć. Marcin dziękuję Ci za sprawdzenie. Szczerze mówiąc, szukając w sieci, nie znalazłem tego typu rozwiązania. Z reguły proponowano wykorzystanie dpkg-statoverride --remove ... itp. Napisałeś, że owe polecenie "przywraca oryginalne atrybuty" - rozumiem, że właściciel dla /bin/su wróci do ustawień domyślnych, czyli root root i nic więcej nie trzeba będzie robić? Mam na myśli działanie z dpkg-statoverride.

Saturno: "Aby w przyszłości nie mieć potrzeby rozwiązywać podobnych kłopotów (...)" - aby uniknąć tego typu odpowiedzi, napisałem że chciałbym poznać rozwiązanie, aby - ewentualnie - pomóc komuś w przyszłości, bowiem jeśli o mnie chodzi obecna sytuacja, skutecznie powstrzyma mnie przed podobnymi testami (vide jest to maszyna testowa.) Niemniej, dziękuję Ci za radę; z pewnością warta jest rozważenia.

Pozdrawiam.

[saturno]

Napisałeś, że owe polecenie "przywraca oryginalne atrybuty" - rozumiem, że właściciel dla /bin/su wróci do ustawień domyślnych, czyli root root i nic więcej nie trzeba będzie robić?

Najprościej sprawdzić ...
A generalnie reinstalacja jakiegoś pakietu powinna przywrócić do oryginału pliki które on zawiera.
A w jakim pakiecie znajduje się: /bin/su można sprawdzić na:
https://packages.debian.org/search?sear ... e&arch=any

[kitek]

Cześć Saturno. Ponieważ nie spotkałem się z podobnym rozwiązaniem, które zaproponował Marcin, zastanawiam się, czy mogą wyniknąć jakieś problemy, np. z logowaniem na konto "zwykłego" użytkownika. (Konto administratora jest w Ubuntu zablokowane, więc teoretycznie nie powinno być komplikacji.) Dziwne, że takie proste, zdawałoby się, rozwiązanie nie jest nigdzie wspomniane albo ja, po prostu nie trafiłem na nie.

Przy okazji: aby sprawdzić w jakim pakiecie znajduje się dany plik, istenieje - według mnie - prostsze rozwiązanie nie wymagające korzystania z przeglądarki itd.:

Kod: Zaznacz cały

[~]$ dpkg -S /bin/su
login: /bin/su

Ale dziękuję Ci za tę informację, ponieważ nigdy nie korzystałem z tego sposobu. Z pewnością się przyda :-) Jeśli chodzi o mój "problem" - sprawdzę sposób Marcina i przeinstaluję pakiet login.

[kitek]

Hej. Przepraszam, że tak długo zajęło mi sprawdzenie rozwiązania zaproponowanego przez marcin1982. Niestety, nic się nie zmieniło. Po wykonaniu operacji przeinstalowania pakietu login, np. polecenie dpkg-statoverride w dalszym ciągu wskazuje, że właścicielami są, odpowiednio: root:adm.

Kod: Zaznacz cały

$ dpkg-statoverride --list
root adm 4750 /bin/su

Podobnie sytuację przedstawia polecenie ls:

Kod: Zaznacz cały

$ ls -al /bin/su
-rwsr-x--- 1 root adm 31116 Dec 13  2012 /bin/su

Co myślicie o metodzie ze zwykłym chown oraz ewentualnie chmod? Zastanawia mnie również, dlaczego nie działa polecenie dpkg-statoverride (z odpowiednimi opcjami: --update --add root root 4750 /bin/su) powodując błąd w postaci nadpisania dla "/bin/su", które już istnieje.

Pozdrawiam.

[pawkrol]

Tak nie działa?

Kod: Zaznacz cały

sudo chown root:root /bin/su

Ewentualnie spróbój zmienić hasło roota w wejść na niego

Kod: Zaznacz cały

sudo passwd root
su

[saturno]

Musisz coś źle robić, bo popatrz:

Kod: Zaznacz cały

tom@ubuntu:/bin$ ls -hal /bin/su
-rwxr-xr-x 1 root adm 38K mar 29  2016 /bin/su
tom@ubuntu:/bin$ sudo apt-get install --reinstall login
[sudo] hasło użytkownika tom: 
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności       
Odczyt informacji o stanie... Gotowe
0 aktualizowanych, 0 nowo instalowanych, 1 ponownie instalowanych, 0 usuwanych i 11 nieaktualizowanych.
Konieczne pobranie 0 B/308 kB archiwów.
Po tej operacji zostanie dodatkowo użyte 0 B miejsca na dysku.
(Odczytywanie bazy danych ... 208060 plików i katalogów obecnie zainstalowanych.)
Przygotowywanie do rozpakowania pakietu .../login_1%3a4.2-3.1ubuntu5_i386.deb ...
Rozpakowywanie pakietu login (1:4.2-3.1ubuntu5) nad (1:4.2-3.1ubuntu5) ...
Przetwarzanie wyzwalaczy pakietu man-db (2.7.5-1)...
Konfigurowanie pakietu login (1:4.2-3.1ubuntu5) ...
tom@ubuntu:/bin$ ls -hal /bin/su
-rwsr-xr-x 1 root root 38K mar 29  2016 /bin/su

[kitek]

Witam. pawkrol; ponieważ konto administratora w systemie Ubuntu jest domyślnie zablokowane (a ja nie zmieniałem tego, tzn. nic nie robiłem z tym kontem), pytałem się, czy np. metoda z chown może być rozwiązaniem. Jeżeli polecana w różnych poradnikach komenda dpkg-statoverride powoduje błąd, być może Twoja sugestia jest dobra.

saturno; wszystko zrobiłem dokładnie tak, jak napisał marcin1982. Zobacz sam:

Kod: Zaznacz cały

[~]$ ls -hal /bin/su
-rwsr-x--- 1 root adm 31116 Dec 13  2012 /bin/su

[~]$ sudo apt-get install --reinstall login
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności       
Odczyt informacji o stanie... Gotowe
[...]
0 aktualizowanych, 0 nowo instalowanych, 1 ponownie instalowanych, 0 usuwanych i 0 nieaktualizowanych.
Konieczne pobranie 0 B/286 kB archiwów.
[...]
Przygotowanie do zastąpienia login 1:4.1.4.2+svn3283-3ubuntu5.1 (wykorzystując .../login_1%3a4.1.4.2+svn3283-3ubuntu5.1_i386.deb) ...
Rozpakowanie pakietu zastępującego login ...
Przetwarzanie wyzwalaczy dla man-db...
Konfigurowanie login (1:4.1.4.2+svn3283-3ubuntu5.1) ...

[~]$ ls -hal /bin/su
-rwsr-x--- 1 root adm 31116 Dec 13  2012 /bin/su

W tej chwili, sprawdziłem to raz jeszcze. Nie mam pojęcia, dlaczego działanie polecenia dpkg-statoverride --update --add root root 4750 /bin/su przerywane jest błędem już istniejącego "nadpisania" dla /bin/su (bez względu na to, czy uruchamiane jest poprzez sudo, czy też nie.) W takim wypadku pozostaje, chyba, metoda z wykorzystaniem chown.

Przy okazji: co myślicie o ręcznej edycji pliku /var/lib/dpkg/statoverride (według polecenia file(1), jest to ASCII text), i zamianie root adm na root root? Nie mam pojęcia, czy jest to w ogóle możliwe, ale czepiam się każdej myśli przed próbą z chown.

===>>> DODANE:
Według tej strony (<http://www.andrewault.net/tag/ubuntu/>) w punkcie mówiącym o zezwalaniu, tylko użytkownikom znajdującym się w grupie admin do korzystania z polecenia su (zob. "Only allow admin users to use su"), wszystko jest normalne -- jeśli chodzi o mój problem. Według wspomnianej strony, prawa dla /bin/su wyglądają, jak w moim przypadku: -rwsr-x--- 1 root admin... A ja właśnie, w celach testowych przeprowadzanych dawno temu, starałem się osiągnąć właśnie taki stan rzeczy. Post edytowałem (aby zwrócić uwagę na fakt "normalności" takiego stanu rzeczy, jaki występuje teraz u mnie), tylko w celach informacyjnych.

Poza tym, zauważyłem że w kilku poradnikach metoda: root admin dla /bin/su jest traktowana jako "Helps prevent privilege escalation". Czyli rodzaj dodatkowego zabezpieczenia. Zalecane jest również dla /usr/bin/sudo. Niemniej, problem wciąż występuje...

Pozdrawiam.