Чи безпечно Vim у поєднанні з судо?

Не доцільно використовувати sudoз графічним додатком gedit, як описано за цим посиланням . Відповідно, я, як правило, використовують vimз sudo.

Нещодавно я помітив, що мені ~/.viminfoналежить root на доволі свіжому встановленні Ubuntu 16.04 (Xenial Xerus), тому мені було цікаво, чи навіть Vim вважається графічним чи є якась інша проблема із викликом sudo vim. Після зміни власності на себе через:

sudo find $HOME -not -user $USER -exec chown $USER:$(id -g) {} +

а згодом запустившись, sudo vimя не міг ~/.viminfo володіти рутом. Однак я впевнений, що останнім часом він був власником root.

Чи не доцільно посилатися sudo vim?

Так, це безпечно.

Проблема sudo geditполягає в тому, що програми GUI використовують певні файли, такі як ~/.cache/dconf, і після geditтого, як файл підвищений , він перебуває у власності root. Добре, що конкретний файл містить налаштування для GUI-програм, зокрема робочого столу, зокрема, якщо система не може прочитати ці налаштування - це погано. Користувач IIRC не може запустити певний робочий стіл. Дані про файли останніх користувачів recently-used.xbelтакож можуть постраждати.

З іншого боку, у Vim немає такої проблеми. Він не використовує бази даних, пов'язаних з графічним інтерфейсом, і нічого не вводить recently-used.xbel. Він був створений лише для консолі, хоча gVim також існує. Насправді, у деяких системах Vim - ваш єдиний вибір редактора. Тож безпечніше, ніж gedit в силу того, що не викликати однакових проблем. Ви все ще редагуєте як root в обох випадках, тому ви можете виникнути проблеми з неправильним редагуванням.

Відповідно до цієї публікації в блозі :

Перший раз, коли ви використовуєте vim, файл ~/.viminfoстворюється, і якщо ви використовуєте sudo vimперший раз, коли ви використовуєте vim після встановлення його в свіжій системі, дозволи на ~/.viminfoвласнику буде встановлено корінь замість користувача за замовчуванням.

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

Дивись також:

• Які конкретні погані речі трапляються, коли gedit використовується із судо?

Це також можна використовувати sudoeditдля досягнення цього; він відкриває тимчасову копію файлу у вашому редакторі, при цьому ваш редактор працює як ви. На чоловіковій сторінці :

1. Тимчасові копії створюються з файлів, які потрібно редагувати разом із власником, встановленим користувачем, що викликає посилання.

2. Редактор, визначений політикою, запускається для редагування тимчасових файлів. Політика sudoers використовує SUDO_EDITOR, VISUALі EDITORзмінні оточення (в такому порядку). Якщо нічого не встановлено SUDO_EDITOR, VISUALабо EDITORне встановлено, використовується перша програма, перелічена в редакторі sudoers(5).

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

Це добре працює з vim (це те, що я зазвичай роблю), і я думаю, що це дозволить вам використовувати також gedit. Існують деякі обмеження безпеки .

Посилання дуже стара (2013). Він рекомендує використовувати gksudoабо gksuдля графічних програм, але обидва вони стають застарілими. Пізніше прийнята відповідь також пропонує sudo -H.

Загальний консенсус у спільноті Ask Ubuntu останнім часом полягає у використанні:

sudo -H gedit /path/to/filename

Єдиною проблемою залишається те, що у sudoнього немає профілю для налаштувань вкладки, розширень, обгортання слів, імені шрифту, розміру шрифту тощо. Ви можете успадкувати їх зі свого профілю користувача, хоча за допомогою сценарію обгортки, як це: Як я можу синхронізувати свій корінь gedit зі своїми вподобаннями користувача gedit?

Так, це безпечно у використанні sudo vim. Проблеми, з якими я стикаюся, є

• Потрібно вийти з файлу та відкрити його знову, sudo vimщоб мати можливість редагувати.

• Маючи корінь vimrcза замовчуванням, а не мої корисні речі.

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

vim() {
    #only good for auto-sudo. delete if no sudo privileges.
    #If you're not just opening a single file, let's not use this.
    if [[ "$#" -ne 1 ]]; then
        command vim "$@"
    #cases: if we can write to the file, or the file doesn't exist and we can make new files in that directory
    elif [[ -w "$1" || ( -w $(dirname "$1") && ! -f "$1" ) ]]; then
        # \vim or 'vim' only escape aliases, not functions
        command vim "$1"
    else
        sudo env HOME="$HOME" vim -u $HOME/.vimrc "$1"
    fi
}

Добре використовувати vi як root. Буде час, коли вам потрібно буде редагувати файл, який вимагає привілеїв sudo або root, наприклад, зміна файлу мережевих інтерфейсів або, можливо, редагування вашого конфігураційного файлу sshd. Використовувати корінь для графічних матеріалів погано, оскільки люди підключаться до IRC або переглядають Інтернет як корінь. Якщо вони отримали вірус, роблячи це, він би мав повний кореневий доступ.

Щось, що не було згадано в інших відповідях, - це те, що запущений vim з root дасть root привілеї для будь-яких встановлених плагінів. Отже, питання про те, чи безпечно це запускати як root, залежить від того, чи довіряєте ви розробникам плагінів (або учасникам їхніх проектів) не володіти вашою системою до основної суті.

Vim, як правило, перевіряється утримувачами пакетів у всіх дистрибутивах Linux, тому легко довіряти. Однак плагіни vim, як правило, встановлюються безпосередньо з репозиторії GitHub і, як правило, мають набагато менше аудитів (можливо, нуль). Іншими словами, з ними не відбувається процес перевірки.

Якщо ви не завантажуєте плагіни під час роботи в root, то, напевно, виконання файлу root залежить від того, чи довіряєте ви розробникам vim. Однак ви можете пропустити довіру до них, скориставшись sudoedit, який роблять ті самі розробники sudo, людям, яким ми вже довіряли кореневий доступ. GKFX і NieDzejkob вже згадували, чому sudoedit ідеальний. Окрім того, що вам не доведеться довіряти кореневий доступ іншим, окрім розробників sudo, ви можете завантажити всі плагіни, яким ви вже довіряли у своєму звичайному обліковому записі користувача.