Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Pracovní prostředí => Téma založeno: kvidok 31 Března 2018, 14:37:15
-
Ubuntu 14.04 LTS.
vik@ubuntu:~$ sudo usermod -a -G sudo did
Po snaze přidat uživatele mn ě systém hází:
sudo: /etc/sudoers je zapisovatelný pro všechny
sudo: no valid sudoers sources found, quitting
sudo: modul s politikami nelze inicializovat
vik@ubuntu:~$
Hledal jsem na Fóru popdobnou chybu, ale zatím se mně to nepodařilo. Prostě "sudo su" nemohu do Terminálu zadat, objeví se pokaždé shora uvedená hláška.
Díky předem za radu.
-
pockej pockej .... :D
a) ti to pise co se deje
b) samo se to asi nestalo ...
ukaz nam prosim vystup z:
ls -l /etc/sudoers
-
vik@ubuntu:~$ ls -l /etc/sudoers
-rwxrwxrwx 1 root root 807 bře 31 08:02 /etc/sudoers
vik@ubuntu:~$
No vzniklo to po nedokončené instalaci PHP5 a pokusu i instalaci PHP7
-
A v sudoers je teďko jen soubor Readme. Týká se to domácího localhost.
Asi použit Recovery mode, ne? Instalace je zřejmě neúplná.
Ve visudo mám toto:
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
Cmnd_Alias vik=/sbin/reboot
restart ALL=(ALL) vik
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
includedir /etc/sudoers.d
příkaz "sudo su" prostě nefunguje ještě např.:
vik@ubuntu:~$ sudo gedit /var/www/html/info.php
sudo: /etc/sudoers je zapisovatelný pro všechny
sudo: no valid sudoers sources found, quitting
sudo: modul s politikami nelze inicializovat
vik@ubuntu:~$
-
nevim, co jsi s tim provedl, ale etc/sudoers ma vypadat takhle:
> ls -l /etc/sudoers
-r--r----- 1 root root 3120 Jul 4 2017 /etc/sudoers
a ma mit primereny obsah .. to znamena, ze ma mit patrne obsah toho, co mas v /etc/visudo + tenhle soubor nema vubec existovat
-
sudo gedit NEMAS vubec pouzivat, protoze to je grafickej program ... mas pouzivat gksudo nebo neco podobneho
-
Takže etc/sudoers mám opravený podle tvého s předešlou kopii u mně takhle:
-r--r----- 1 root root 807 bře 31 08:02 /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
# includedir /etc/sudoers.d
Přesto ale sudo su nelze vyvolat...
-
vik@ubuntu:~$ su
Heslo:
su: Selhání autentizace
vik@ubuntu:~$
su tedy nefunguje, zkusím tedy v bash:
user @ host: ~ $ sudo bash
root @ host: ~ # su
root @ host: / home / user #
-
Docela by mě zajímala historie tvého bashe, k takové prasárně nedojde jen tak a soubor visudo s obsahem sudoers sis musel sám vytvořit. visudo je příkaz, kterým se sudoers edituje, umí totiž oproti běžnému editoru kontrolovat správnost syntaxe, což je u tohoto souboru velmi užitečné ze stejného důvodu, který se tu řeší.
Ten řádek z výstupu ls -l, který poslal ntz, ukazuje správné nastavení práv /etc/sudoers, ne řádek, kerý máš přidat. Pokud má soubor špatně nastavená práva, nebude sudo z bezpečnostních důvodů fungovat. Správná práva lze nastavit buď příkazem:
pkexec chmod 0440 /etc/sudoersnebo postaru bootem do recovery módu, připojením systémového disku pro zápis a spuštěním stejného příkazu bez pkexec.
Otázkou je, zda nemají poškozená práva i další systémové soubory a pokud to nemáš pod kontrolou, může být reinstalace systému rozumné řešení.
-
Jo, máš pravdu historie je pro mě zvláštrní.
Vůbec nevím, od kdy se mně /etc/sudoers a /etc/sudoers.d/ objevily v adresáři a začaloo mi hlásit při zadání sudo su tu větší hlášku, jak je psáno nahoře-
Kde se sudoers vzal? Při instalaci PHP7, která se mně nepodařila?
Zkusím tedy nastavit práva, jak píšeš:
pkexec chmod 0440 /etc/sudoers
Pořád stejný problém např při su:
vik@ubuntu:~$ su
Heslo:
su: Selhání autentizace
vik@ubuntu:~$
-
Tak jsem zjistil zde:
ubuntu.com/manpages/bionic/man8/pwconv.8.html (http://ubuntu.com/manpages/bionic/man8/pwconv.8.html)
že existuje nástroj pwconv, který opraví případné nesrovnalosti. Má to být program grpconv pro skupiny v / etc / gshadow.
V gshadow mám tohle:
root:*::
daemon:*::
bin:*::
sys:*::
adm:*::vik,syslog
-
su samotné (ne)funguje správně, se sudoers nemá nic společného a vyžaduje heslo roota, který v ubuntu ve výchozím stavu jako klasický uživatel neexistuje a existovat nemá. Je možné su použít právě se sudo, nebo pkexec, ale v podstatě to nedává smysl, protože oba příkazy umí to samé i bez su, s patřičným přepínačem.
Příkaz pkexec je určen k tomu samému, co sudo a bude fungovat, i když je /etc/sudoers poškozen, protože jeho nastavení definuje úplně jiná sada pravidel založená na PolicyKit.
-
@Gdh
Tohle také nepomohlo.
Prostě, jestli se nemýlim, tak / etc / sudoers umožňuje spouštět démona jako root bez hesla pomocí směrnice NOPASSWD.
Ale můj problém je, že tohle nikde nevidím, protože soubor sudoers je prázdný!???
Navíc jsem ve verzi 16.04 LTS měl v adresáři: /etc/sudoers.d/
To teď ve verzi 14.04. LTS nemám.....
Takže jsem provedl Recovery mode:
mount -n -o remount,rw /
chmod u+x /etc/sudoers
nano /etc/sudoers
Teď se již objevila složka /etc/sudoers.d
-
Já to nepsal jako návod, ale jako info, abys pochopil, proč se to chová tak, jak se to chová a doufal jsem, že si všechny ty informace poskládáš sám.
Jak má vypadat soubor /etc/sudoers sis tu vypsal sám, tvrdil jsi, že je to obsah souboru visudo. Z toho vyplývá, že sis sudoers nejspíš jednoduše přejmenoval. Pak jsi vložil i výchozí verzi sudoers, kam jsi ale zjevně připsal nesmyslný řádek s výpisem příkazu ls -l.
Ntz ti ukázal, jak mají vypadat práva /etc/sudoers, já ti napsal, jak toho docílíš.
Další info.
Soubor /etc/sudoers obecně obsahuje pravidla pro chování příkazu sudo a umožňuje, mimo jiné, i povolit použití sudo bez nutnosti zadávání hesla v konkrétních případech, jak jsi naznačil. Bez tohoto souboru sudo nemůže vůbec fungovat a tudíž tam byl už od instalace systému.
/etc/sudoers.d je adresář, kam se dají dopisovat další pravidla do samostatných souborů a pokud je v sudoers patřičný řádek s příkazem includedir, importují se tato pravidla také, jako by byla zapsána přímo v /etc/sudoers. Ve výchozím stavu se ale tento adresář nevyužije, protože je řádek s importem v sudoers zakomentován.
-
@GdH
Tak konečně!!!!!
Po novém zápisu (nakopírování obsahu) sudoers a správných právech podle Tebe:
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
vik ALL = (ALL) NOPASSWD: / usr / bin / thurderbird // je to specifické povolení
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
#%sudo ALL=(ALL:ALL) ALL
dolly ALL=(ALL) NOPASSWD:/usr/bin/thurderbir
To začíná fachčit, sudo jede tak, že NAPSAL:
vik@ubuntu:~$ sudo su
[sudo] password for vik:
vik není v souboru sudoers. Tento událost bude ohlášena.
vik@ubuntu:~$
To snad již dořeším do úspěšného konce....
Řešení:
Dopsán řádek:
%vik ALL=(ALL:ALL) ALL
-
FUNGUJE!!!!!!
vik@ubuntu:~$ pkexec chmod 0440 /etc/sudoers
vik@ubuntu:~$ sudo su
[sudo] password for vik:
root@ubuntu:/home/vik#
Hodně díky za info a čas zde především:
@GdH
@ntz_reloaded
Zdravím a máme tu šmigrust!!!
-
Správnějším řešením je uživatele vik přidat do skupiny sudo, která má v sudoers již garantována práva.
usermod -a -G sudo vikJinak mezi výchozí skupiny admina v ubuntu patří tyto (příklad výpisu pro mého uživatele):
gdh@gdh:~$ groups gdh
gdh : gdh adm cdrom sudo dip video plugdev lpadmin sambashare systemd-journal
U verze 14.04 si nejsem jist jen skupinou systemd-journal.
Ty řádky s thunderbirdem bych řekl, že nebudou fungovat..
-
vik@ubuntu:~$ su
Heslo:
su: Selhání autentizace
vik@ubuntu:~$
su tedy nefunguje, zkusím tedy v bash:
user @ host: ~ $ sudo bash
root @ host: ~ # su
root @ host: / home / user #
nazdar ... ja jeste nechapu tohle .. dyk tady nevidim pokus o to udelat `sudo su' ... protoze nejdriv delas su bez sudo a pak delas z nepochopitelneho duvodu su po `sudo bash' :D
ono je totiz ostatne dulezite vedet, co chces vlastne udelat .. pokud se chces prihlasit na roota, tak pouzij `sudo -i' (to je v podstate to stejne, co `su -'), pokud chces pouzit prikaz 'su' tak ho pouzij se sudo ... ja osobne defaultni ubunti model se sudo, kdy nezadavas heslo roota ale heslo obycejneho uzivatele, povazuju za naprostej blaznivej a jeste mnohem vic nebezpecnej *censored*, nez mit nastaveno separatni heslo na roota ...
-
vik@ubuntu:~$ su
Heslo:
su: Selhání autentizace
vik@ubuntu:~$ sudo su
[sudo] password for vik:
Jo, výhradně zadávám "sudo su"!
-
@GdH
Ale myslím, že tohle je dost nebezpečné, ne?
#%sudo ALL=(ALL:ALL) ALLJe to pro všechny. Či mám odkomentovat?
Ty řádky s thunderbirdem bych řekl, že nebudou fungovat..
Fungují, není problém
-
@GdH
Ale myslím, že tohle je dost nebezpečné, ne?
#%sudo ALL=(ALL:ALL) ALLJe to pro všechny. Či mám odkomentovat?
Ten řádek dává právo používat příkaz sudo pouze uživatelům, kteří patří do skupiny sudo. Běžně se uživatelé, kteří mají mít toto právo, přidávají do této skupiny, místo aby se kvůli nim přepisoval sudoers.
...
ja osobne defaultni ubunti model se sudo, kdy nezadavas heslo roota ale heslo obycejneho uzivatele, povazuju za naprostej blaznivej a jeste mnohem vic nebezpecnej *censored*, nez mit nastaveno separatni heslo na roota ...
Já bych řekl, že výhody zásadně převažují, zvláště na systému pro obyčejné uživatele :)
-
Aha.
Takže měním na:
sudo ALL=(ALL:ALL) ALL
a vik a dolly dávám zakomentované, než je odstraním úplně
#vik ALL = (ALL) NOPASSWD: / usr / bin / thurderbird // je to specifické povolení
#dolly ALL = (ALL) NOPASSWD: / usr / bin / thurderbird // je to specifické povolení
-
...
ja osobne defaultni ubunti model se sudo, kdy nezadavas heslo roota ale heslo obycejneho uzivatele, povazuju za naprostej blaznivej a jeste mnohem vic nebezpecnej *censored*, nez mit nastaveno separatni heslo na roota ...
Já bych řekl, že výhody zásadně převažují, zvláště na systému pro obyčejné uživatele :)
rozhodne neprevazuji podle meho nazoru .. prevazovaly by, ale ne na typicke workstation, kde ti pod stejnym uzivatelem bezi napr. prohlizec a nebo (casto) proprietalni *censored* jako hry ze steamu, skype a kdovi co jeste napr. pod wine apod ... alespon podle meho nazoru
to, ze se sudo pouziva jako vychozi snad jen kvuli tomu, aby nebylo mozny bruteforcovat heslo na roota, je relikt s nepochopitelnejma a iracionalnima zakladama ...
ps. me trvalo asi tak 15 let linuxovani nez jsem pochopil, ze bezici sshd na my workstation je naprosta ptakovina ;)
-
....
rozhodne neprevazuji podle meho nazoru .. prevazovaly by, ale ne na typicke workstation, kde ti pod stejnym uzivatelem bezi napr. prohlizec a nebo (casto) proprietalni *censored* jako hry ze steamu, skype a kdovi co jeste napr. pod wine apod ... alespon podle meho nazoru
to, ze se sudo pouziva jako vychozi snad jen kvuli tomu, aby nebylo mozny bruteforcovat heslo na roota, je relikt s nepochopitelnejma a iracionalnima zakladama ...
ps. me trvalo asi tak 15 let linuxovani nez jsem pochopil, ze bezici sshd na my workstation je naprosta ptakovina ;)
Takový uživatel má sice možnost použít sudo, ale bez hesla nemá žádná práva navíc, oproti uživateli bez sudo a ty aplikace se k heslu sudoera přeci nedostanou jednodušeji, než k heslu roota. Pokud by uživatel začal používat účet roota, který má od přírody všechna práva vždy, rozhodně bych to neviděl jako minimalizaci rizik. Důvody, proč sudo ano a ne, jsou vypsány třeba zde: https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo (https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo) , klidně nám ntz napiš další postřehy, které tam nejsou.
-
....
rozhodne neprevazuji podle meho nazoru .. prevazovaly by, ale ne na typicke workstation, kde ti pod stejnym uzivatelem bezi napr. prohlizec a nebo (casto) proprietalni *censored* jako hry ze steamu, skype a kdovi co jeste napr. pod wine apod ... alespon podle meho nazoru
to, ze se sudo pouziva jako vychozi snad jen kvuli tomu, aby nebylo mozny bruteforcovat heslo na roota, je relikt s nepochopitelnejma a iracionalnima zakladama ...
ps. me trvalo asi tak 15 let linuxovani nez jsem pochopil, ze bezici sshd na my workstation je naprosta ptakovina ;)
Takový uživatel má sice možnost použít sudo, ale bez hesla nemá žádná práva navíc, oproti uživateli bez sudo a ty aplikace se k heslu sudoera přeci nedostanou jednodušeji, než k heslu roota. Pokud by uživatel začal používat účet roota, který má od přírody všechna práva vždy, rozhodně bych to neviděl jako minimalizaci rizik. Důvody, proč sudo ano a ne, jsou vypsány třeba zde: https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo (https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo) , klidně nám ntz napiš další postřehy, které tam nejsou.
sudo kesuje ve vychozim stavu na iirc 10 nebo 15 minut heslo ... to je zlo jako svine .. ;)
-
sudo kesuje ve vychozim stavu na iirc 10 nebo 15 minut heslo ... to je zlo jako svine .. ;)
Když si otevřeš terminál přes su a timeout nemáš žádný, jaký je v tom pro tebe bezpečnostní benefit? Navíc sudo platí pouze pro jeden příkaz a další potřebuje další sudo, i když do timeoutu bez hesla.
-
jsou tady proste teoreticke moznosti zneuziti, zejm. od ruznych programu 3ti stran nebo ruznejch freewaru a aplikaci co jdou napr. pres wine, ktere pri sve invokaci vyzkousi, jestli nahodou nemas v soucasnem terminalu sudo s otevrenou session apod ...
pokud je uzivatel natolik uvedomelej, ze danej shell po pouziti sudo ihned zavre, tak okay, jinak mi to pripada, ze pro typickeho uzivatele to naprosto zadnou bezpecnost navic neprinasi ... a o to jde
-
Nenabizi se pak proste vypnuti cacheovani tohoto hesla?