Domyślni właściciele / uprawnienia plików w katalogu osobistym użytkownika


14

Często widzę użytkowników, którzy próbują naprawić problem i gdzieś czytają lub po prostu próbują rekursywnie chownswój katalog domowy, a czasem nawet rekurencyjnie resetują uprawnienia do czegoś podobnego rwxr-xr-xlub podobnego.

Wyobraź sobie masakrę takiego właściciela / uprawnień - czy istnieją krytyczne pliki / katalogi, które wymagają specjalnych uprawnień lub muszą być własnością root, aby system działał?


1
Pliki Wat, o których mówisz? Dlaczego krytyczne pliki należące do roota miałyby być w domu użytkownika?
mikewhthing

1
@mikewhatever Znam przynajmniej trzy katalogi, które muszą być root: ~/.gvfs/, ~/.cache/gvfs-burn/i ~/.cache/dconf. Prawdopodobnie jest ich więcej.
Bajt Dowódca

1
drwx------ 2 romano romano 4096 dic 2 2008 .gvfsi nigdy nie miałem żadnych problemów .... (zobacz datę). Równieżdrwx------ 2 romano romano 4096 abr 28 14:57 .cache/dconf
Rmano

3
W katalogu domowym użytkownika nie ma plików „krytycznych”, jeśli są, to wynik bardzo złego programowania, ponieważ użytkownik może je usunąć celowo / przez pomyłkę w trybie flash. O ile nie jest to pomyłka, pliki „krytyczne” są przechowywane gdzie indziej.
Kos

FWIW, mogę potwierdzić, że ~ / .gvfs i ~ / .cache / dconf w moim systemie są własnością root. Uruchomiłem „sudo ls -Al” w obu katalogach i oba są puste. Chociaż zmieniłem uprawnienia grupowe i inne dla dokumentów, nigdy nie uruchomiłem Chown. Tak więc własność root dla tych dwóch katalogów może być normalna, przynajmniej dla Ubuntu 15.04. Ponadto nie mam katalogu ~ / .cache / gvfs-burn ani katalogów ipc-admin wspomnianych przez Byte Commander, które są własnością root. Ale plik o nazwie alfanumerycznej w ~ / .dbus / session-bus jest własnością Mnie, a nie roota.
user173876,

Odpowiedzi:


17

Plik ~root nie może należeć do użytkownika root.

Jeśli oprogramowanie wymaga, że plik w swoim katalogu domowym być własnością przez innego użytkownika, to jest błąd i powinno zostać zgłoszone jako takie.

Poza tym powszechny przypadek dotyczy dwóch programów związanych z bezpieczeństwem, które wymagają ograniczonych uprawnień do niektórych plików, a mianowicie:

  1. SSH
  2. GPG

SSH

Patrz man sshsekcja FILES:

 ~/.ssh/config
     This is the per-user configuration file.  The file format and
     configuration options are described in ssh_config(5).  Because of
     the potential for abuse, this file must have strict permissions:
     read/write for the user, and not writable by others.  It may be
     group-writable provided that the group in question contains only
     the user.

 ~/.ssh/identity
 ~/.ssh/id_dsa
 ~/.ssh/id_ecdsa
 ~/.ssh/id_ed25519
 ~/.ssh/id_rsa
     Contains the private key for authentication.  These files contain
     sensitive data and should be readable by the user but not acces‐
     sible by others (read/write/execute).  ssh will simply ignore a
     private key file if it is accessible by others.  It is possible
     to specify a passphrase when generating the key which will be
     used to encrypt the sensitive part of this file using 3DES.

Inne pliki, takie jak authorized_keys, known_hostsitd powinny być zapisywalny tylko przez użytkownika, ale mogą być światowej czytelny.

GnuPG

~/.gnupg(i zawartość) powinny być dostępne tylko dla Ciebie. W przypadku innych uprawnień GPG będzie narzekać na niebezpieczne uprawnienia.


A co z ~/.gvfs/, ~/.cache/gvfs-burn/i ~/.cache/dconf? Są własnością root i myślę, że powinny.
Bajt Dowódca

2
@ByteCommander nie. Używałeś sudoz programami GUI?
muru

Nie, żebym to pamiętał ... Tworzę nowego użytkownika i sprawdzam tam. Chwileczkę.
Bajt Dowódca


1
@ByteCommander, jeśli taka była intencja, to sudo -ilub sudo -Hprawdopodobnie należy go użyć.
muru

11

Ogólnie pliki i katalog w twoim domu powinny być własnością ciebie.
Mam dziwne pliki należące do roota, które prawdopodobnie wynikają z wykonania sudopolecenia; w rzeczywistości istnieją programy, w których piszą rzeczy $HOME(które dobrze zachowujące się programy wymagające uprawnień superużytkownika nie powinny robić --- efektem jest przejęcie przez root własności plików, które powinny należeć do użytkownika).
Zwykle ich usuwanie lub ponowne posiadanie (w zależności od pliku) nie stwarza problemów i często rozwiązuje niektóre problemy, takie jak niesławny .Xauthorityplik --- a czasem po uruchomieniu sudo dconf-editormasz rzeczy w konfiguracjach, których nie możesz już modyfikować.

O trybach specjalnych:

  • skrypty muszą być oczywiście wykonywalne przynajmniej dla właściciela;
  • tak samo muszą być katalogi (gdzie xoznacza prawo do przekreślenia);
  • .sshmusi być drwx------(0700) i zawierać w nim klucze prywatne -rw-------(0600)
  • jeśli masz Publickatalog do udostępniania, prawdopodobnie powinien to być drwxr-xr-x(uprawnienie do odczytu dla każdego) lub drwxrwxrwt(z uprawnieniem do zapisu i lepką częścią, aby umożliwić zapis).

... Nie mogę myśleć o niczym więcej wymagającym specjalnego traktowania.


A co z ~/.gvfs/, ~/.cache/gvfs-burn/i ~/.cache/dconf? Są własnością root i myślę, że powinny.
Bajt Dowódca

@ByteCommander --- wszystkie te rzeczy należą do mnie w moim systemie i nic nie działa prawidłowo. Jak myślisz, dlaczego muszą być własnością roota? W dconfjest twoja konfiguracja, a uprzywilejowane polecenie / demon, który wykonuje montowanie partycji, powinien zmienić właściciela na ciebie --- w przeciwnym razie jest to błąd. Skomentowałem to w twoim pytaniu.
Rmano,

Znalazłem jeszcze dwa pliki root, że nie jestem pewien, czy to dobrze, czy źle: ~/.dbus/session-bus/7ae519bec942595a6925fb2d5448031b-1i /home/ipc-admin/.aptitude/configwiele rzeczy pod /home/ipc-admin/.cache/pip/wheels/, /home/ipc-admin/.local/share/session_migration-(null)i /home/ipc-admin/.local/share/applications/mimeapps.list. Czy możesz sobie wyobrazić, dlaczego są one własnością root w moim systemie?
Bajt Dowódca
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.