Власники / дозволи файлів за замовчуванням у домашньому каталозі користувача


14

Я часто бачу користувачів, які намагаються виправити проблему і десь читають або просто намагаються рекурсивно chownїх домашній каталог, а іноді навіть рекурсивно скидають дозволи на щось подібне rwxr-xr-xчи подібне.

Уявіть собі таку різанину з власником / дозволом - чи існують критичні файли / каталоги, які потребують спеціальних дозволів або мають бути власністю root для роботи системи?


1
Ват файли ви говорите? Чому критичні файли, що належать root, перебувають у будинку користувача?
mikew незалежно від

1
@mikewhatever Я знаю , по крайней мере , три директорії , які повинні належати корені: ~/.gvfs/, ~/.cache/gvfs-burn/і ~/.cache/dconf. Напевно, є і більше.
Байт-командир

1
drwx------ 2 romano romano 4096 dic 2 2008 .gvfsі ніколи не було жодних проблем .... (див. дату). Такожdrwx------ 2 romano romano 4096 abr 28 14:57 .cache/dconf
Рмано

3
У домашньому каталозі користувача немає "критичних" файлів, якщо такі є, то це результат дуже поганого програмування, оскільки користувач може видалити їх навмисно / помилково у мить. Якщо це не помилка, "критичні" файли зберігаються в іншому місці.
kos

FWIW, я можу підтвердити, що ~ / .gvfs та ~ / .cache / dconf в моїй системі обидва належать root. Я побіг "sudo ls -Al" в обох каталогах, і вони обоє порожні. Хоча я змінив групові та інші дозволи на документи, я ніколи не працював на чоун. Отже, власність root на ці два каталоги цілком може бути нормальною, принаймні для Ubuntu 15.04. Крім того, у мене немає каталога ~ / .cache / gvfs-burn або каталогів ipc-admin, згаданих Byte Commander, які належать root. Але, файл з ім'ям числових альфа в ~ / .dbus / session-bus належить мені, а не root.
користувач173876

Відповіді:


17

НЕ файл ~повинен бути власником root.

Якщо програмне забезпечення вимагає, щоб файл у вашому домашньому каталозі належав іншому користувачеві, це помилка, і про нього слід повідомити.

Окрім цього, звичайний випадок стосується двох програм, пов’язаних із безпекою, які потребують обмежених дозволів на певні файли, а саме:

  1. SSH
  2. GPG

SSH

Дивіться man sshрозділ 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.

Інші файли, наприклад authorized_keys, known_hostsтощо, повинні записуватися лише користувачем, але вони можуть читатись у всьому світі.

GnuPG

~/.gnupg(та вміст) має бути доступний лише вам. З іншими дозволами GPG скаржиться на небезпечні дозволи.


То що ~/.gvfs/, ~/.cache/gvfs-burn/а ~/.cache/dconf? Вони належать до кореня, і я думаю, що вони повинні бути.
Байт-командир

2
@ByteCommander nope. Використовуєте sudoз програмами GUI, чи не так?
муру

Не те, щоб я міг це запам'ятати ... Я створюю нового користувача і там перевіряю. Будь ласка, хвилиночку.
Байт-командир

@ByteCommander мають погляд: bugzilla.gnome.org/show_bug.cgi?id=534284
muru

1
@ByteCommander, якщо це було наміром, то sudo -iабо, sudo -Hмабуть, його слід використовувати.
муру

11

Загалом файли та каталог у вашому домі мають бути вами.
У мене є деякі дивні файли, що належать root, які, ймовірно, є результатом виконання sudoкоманди; насправді є програми, в яких записуються речі $HOME(які добре поводяться з програмами, які вимагають привілеїв суперкористувача, не повинні робити --- ефект полягає в тому, що кореневі права власності на файли, які повинні належати користувачеві).
Зазвичай видалення або повторне володіння ними (залежно від файлу) не створює проблем, і часто він вирішує деякі, як сумнозвісний .Xauthorityфайл ---, а іноді після запуску у sudo dconf-editorвас є речі в конфігураціях, які ви більше не можете змінювати.

Про спеціальні режими:

  • сценарії повинні бути виконані, звичайно, принаймні власнику;
  • так повинні бути і каталоги (де xозначає, що правильно перетинати);
  • .sshмає бути drwx------(0700) та приватними ключами в ньому -rw-------(0600)
  • якщо у вас є Publicкаталог для спільного використання, це, мабуть, має бути drwxr-xr-x(читання дозволу будь-кому) або drwxrwxrwt(з дозволом на написання та клейким бітом для ввімкнення написання).

... Я не можу думати більше про щось, що потребує спеціального лікування.


То що ~/.gvfs/, ~/.cache/gvfs-burn/а ~/.cache/dconf? Вони належать до кореня, і я думаю, що вони повинні бути.
Байт-командир

@ByteCommander --- все, що мені належить у моїй системі, і нічого не працює. Чому, на вашу думку, вони повинні володіти коренем? У dconfце ваша конфігурація, і привілейована команда / демон , який робить монтаж перегородок повинні перейти в власність до вас --- в іншому випадку це помилка. Я прокоментував це ваше запитання.
Рмано

Я знайшов ще два файли, що належать root, і я не впевнений, це правильно чи неправильно: ~/.dbus/session-bus/7ae519bec942595a6925fb2d5448031b-1і /home/ipc-admin/.aptitude/config, багато матеріалів під /home/ipc-admin/.cache/pip/wheels/, /home/ipc-admin/.local/share/session_migration-(null)та /home/ipc-admin/.local/share/applications/mimeapps.list. Чи можете ви уявити, чому вони належать до моєї системи?
Байт-командир
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.