- Root ofereix control total, però Ubuntu i altres distribucions ho mantenen desactivat per defecte per reduir riscos.
- Sudo permet elevar privilegis de forma puntual i deixa registre de qui executa cada ordre.
- Per a aplicacions gràfiques hi ha helpers com kdesu, gksu, gksudo o pkexec, que es poden fer servir en llançadors .desktop.
- La seguretat depèn de fer servir privilegis mínims, evitar scripts no fiables i auditar els accessos elevats.
Al Windows molta gent està acostumada a prémer Shift+Enter o Shift+clic esquerre per obrir un programa amb permisos elevats des del menú d'inici. A Linux aquest costum no sempre es tradueix de manera directa, perquè la seguretat es recolza en root, sudo i helpers gràfics , i cada entorn d'escriptori té les seves pròpies eines. Tot i així, sí que hi ha maneres força senzilles de llançar aplicacions com root des d'un llançador, un accés directe o el menú d'aplicacions, encara que convé entendre bé què implica fer-ho.
La clau és que l'usuari root té el control absolut del sistema i que les distribucions modernes, sobretot Ubuntu i derivats, solen mantenir-lo desactivat per a inici de sessió directe. Per això el més normal no és entrar com a root, sinó elevar privilegis de forma puntual amb sudo o amb un programa gràfic que demani la contrasenya. Si volem que una icona del launcher arrenqui una app amb aquests privilegis, haurem de modificar l'ordre que executa o crear un llançador específic.
Què significa realment executar alguna cosa com a root
A Linux, root és el compte amb UID 0 i permisos il·limitats . Podeu llegir, modificar o esborrar qualsevol fitxer, instal·lar programari, canviar configuracions del nucli i controlar processos de qualsevol usuari. Això ho converteix en una eina potentíssima, però també en un risc enorme si es fa servir sense cura. Un simple error tipogràfic amb rm o mv pot deixar el sistema inservible, i un script maliciós executat com a root pot instal·lar portes del darrere, modificar defenses o robar dades gairebé sense deixar rastre clar.
A Ubuntu, el compte root no té una contrasenya assignada per defecte i no es permet l'inici de sessió directe. La filosofia és que treballis amb el teu usuari normal i facis servir suo per a tasques concretes . sudo significa, en essència, executar una ordre com un altre usuari, normalment root, després d'autenticar-te amb la teva pròpia contrasenya si pertanys al grup sudo. Així es limita el temps dexposició i es deixa un registre de qui va fer què.
No obstant això, en situacions molt concretes, com ara recuperar un sistema danyat, treballar en entorns restringits o configurar serveis que necessiten accés persistent, es pot plantejar habilitar root de manera temporal. La recomanació general és tornar-lo a desactivar quan acabi aquesta necessitat. Com menys temps passis com a root, millor per a l'estabilitat i la seguretat de la màquina.
Riscos d'usar root sense precaució
Un dels perills més evidents és l' eliminació accidental d'arxius vitals . Com a root no hi ha barreres de permisos, una ordre com a sudo rm -rf / pot arrasar el sistema sense preguntar. Tampoc hi sol haver paperera de reciclatge per a aquests esborrats, així que la recuperació pot exigir eines forenses complexes o directament reinstal·lar el sistema.
Un altre risc és executar scripts no fiables. Si llences codi descarregat de qualsevol lloc amb privilegis elevats, li estàs donant les claus de casa teva . Encara que l'script sembli inofensiu, pot contenir instruccions destructives o instal·lar codi maliciós amb permisos de root. Per això convé revisar el codi, fer servir fonts oficials, comprovar sumes de verificació i provar en una màquina virtual o contenidor abans d'executar-lo en producció.
També hi ha un problema de traçabilitat. Quan feu servir suo, el sistema registra a /var/log/auth.log, /var/log/secure o journalctl l'ordre, l'usuari que el va llançar i el moment. Si entres directament com a root, tot apareix com a root i perds la capacitat de saber quina persona física va fer cada canvi. En entorns amb diversos administradors o auditories ISO 27001, PCI DSS, etc., aquesta manca de rastre és una debilitat important.
Formes d'obtenir privilegis des de la terminal
La forma més habitual i recomanada és anteposar sudo a una ordre concreta. Per exemple, per actualitzar paquets, reinicieu un servei o editeu un fitxer protegit. sudo us demanarà la vostra contrasenya d'usuari, no la de root, i després d'autenticar-te executarà l'ordre amb privilegis elevats. Si necessiteu executar com un altre usuari diferent, podeu utilitzar sudo -o nom_usuari ordre . I si t'adones que vas oblidar posar sudo, pots repetir l'última ordre amb sudo !!.
Quan fas diverses tasques administratives seguides, pot resultar còmode obrir una shell de root temporal. sudo -i simula un inici de sessió complet de root, carrega el seu entorn i et deixa al vostre directori personal. sudo seu o sudo su – també serveixen, encara que suo -i sol ser més consistent. Per sortir d'aquesta sessió, només cal escriure èxit. No convé deixar una shell de root oberta sense vigilància.
La comanda, per la seva banda, canvia d'usuari. el seu – root o simplement el seu – adopten també les variables d'entorn de l'usuari destí, mentre que el seu root o sense guió manté part de l'entorn anterior. Aquesta diferència explica errors del tipus command not found: les ordres d'administració solen ser a /usr/local/sbin, /usr/sbin i /sbin, rutes que no sempre apareixen al PATH d'un usuari normal. Si utilitzeu el vostre sense guió, haureu d'escriure la ruta completa o canviar a la seva – per heretar el PATH de root.
Si vols habilitar una contrasenya per a root, ho pots fer amb sudo passwd root . Ubuntu ho desaconsella, però tècnicament permet que root tingui clau. Per bloquejar el compte, s'utilitza sudo passwd -l root , i per desbloquejar-lo, sudo passwd -u root. A SSH, l'accés directe de root es controla amb PermitRootLogin a /etc/ssh/sshd_config. El més segur és mantenir-lo en no o, a tot estirar, prohibit-password per permetre només claus SSH. Després cal reiniciar el servei ssh.
Configurar sudoers amb precisió
El fitxer /etc/sudoers defineix qui pot fer servir suo i per a què. No convé editar-lo a mà: el correcte és utilitzar sudo visut , que bloqueja el fitxer i comprova la sintaxi abans de desar. La regla bàsica té la forma usuari host=(usuari_destinació) ordres. Per exemple, bob ALL=(ALL) ALL permet a bob executar qualsevol ordre com a root en qualsevol equip. També es poden fer servir grups, com %admin ALL=(ALL) ALL.
Per donar permisos més fins es fan servir àlies. User_Alias ADMINS = alice, bob agrupa usuaris, i Cmnd_Alias LOCATE = /usr/sbin/updatedb agrupa ordres. Després s'escriu ADMINS ALL = LOCATE perquè aquests usuaris només puguin llançar aquestes ordres. Es poden crear àlies com NETWORKING amb route, ifconfig, ping, iptables, etc. Així s'aplica el principi de privilegi mínim sense donar root complet a ningú.
L'opció NOPASSWD permet executar certes ordres sense contrasenya, per exemple pi ALL=(ALL) NOPASSWD: ALL. És còmode però perillós si s'abusa. A més, cada ús de sudo queda registrat, cosa que ajuda a auditar accessos ia resoldre problemes. Si alguna cosa es trenca, revisar aquests registres pot indicar quin canvi recent va causar la decisió.
Llançar aplicacions gràfiques com a root des del launcher
Per a programes amb interfície gràfica, fer servir sudo a seques no sol funcionar bé perquè no hi ha terminal on demanar la contrasenya. Aquí entren els helpers gràfics . Al KDE existeix kdesu : si sabeu quina ordre llança l'aplicació, podeu executar kdesu aquest_ordre. L'opció Executar ordre del menú del KDE també permet llançar una aplicació com un altre usuari introduint les credencials. En GNOME i entorns GTK es va usar molt gksu i gksudo , que són frontends de sudo o la seva. Per exemple, gksu synaptic o gksudo gparted obren l'app preguntant la contrasenya.
En sistemes moderns, gksu està desaconsellat o directament retirat. La seva alternativa habitual és pkexec , basat en PolicyKit, que permet executar programes amb privilegis segons polítiques definides. Molts llançadors actuals usen pkexec per a tasques administratives. La idea és la mateixa: que lusuari no hagi dobrir una terminal, però que el sistema validi lautorització de forma controlada.
Per crear un accés directe al launcher, s'edita un fitxer .desktop . La línia Exec és la que mana. Si voleu arrencar com a root, podeu posar alguna cosa com Exec=gksu /ruta/al/programa, Exec=kdesu /ruta/al/programa o Exec=pkexec /ruta/al/programa. Si fas servir suo directament, necessitaràs que el llançador tingui Terminal=true o configurar un askpass gràfic. També podeu provar des d'Alt+F2 escrivint el helper i el programa, per exemple gksu synaptic. Al KDE, kdesu synaptic o l'opció d'executar com un altre usuari fa un paper semblant.
Hi ha una alternativa clàssica anomenada consolehelper , un embolcall per a aplicacions GUI. Es crea un enllaç simbòlic, per exemple /usr/bin/xterm-root apuntant a /usr/sbin/consolehelper. Després es configura PAM creant /etc/pam.d/xterm-root amb les inclusions auth, account i session de config-util. Després es defineix /etc/security/console.apps/xterm-root amb USER=root i PROGRAM=/usr/bin/xterm. En executar xterm-root, consolehelper demana autenticació segons PAM i llança xterm com a root. Si apareix un error Xlib connection to :0.0 refused by server, podeu ajudar a executar xhost local:root.
En qualsevol cas, obrir aplicacions gràfiques com ara root té pegues: barreja variables d'entorn, pot trencar el bus de sessió, afectar Wayland o X11 i crear fitxers propietat de root a la teva carpeta personal. És millor fer-lo servir només per a eines administratives concretes i tancar-les quan acabis. No naveguis per internet ni obris documents sospitosos com root , perquè qualsevol exploit heretaria privilegis totals.
Exemples habituals de tasques que demanen root
Moltes operacions del dia a dia requereixen privilegis elevats. Gestionar paquets amb apt, zypper, dnf o yum sol necessitar sudo. Per exemple, sudo apt update , sudo apt install firefox o sue zypper install docker-ce. També passa amb serveis del sistema: sudo systemctl restart apache2, sudo systemctl restart ssh o sudo systemctl restart nginx. Per modificar comptes d'usuari es fa servir sudo usermod, i per canviar propietaris de fitxers, sudo chown. Editar configuracions crítiques, com ara /etc/ssh/sshd_config, també exigeix permisos de root si es fa amb nano, vim o gedit.
No cal sudo per a ordres que només llegeixen informació o no modifiquen el sistema, com zypper repos o systemctl status NetworkManager. Aplicar sudo a tot per costum és una pràctica dolenta. El que és sensat és elevar permisos només quan la tasca ho exigeix i tornar com més aviat millor a l'usuari normal.
Bones pràctiques en treballar amb privilegis elevats
El principi de privilegi mínim hauria de guiar-ho tot. Usa sudo per a ordres individuals sempre que puguis, evita shells persistents de root excepte necessitat i sal amb èxit quan acabis. No executis scripts de fonts desconegudes com a root, revisa el codi abans, descàrrega de repositoris oficials o projectes prestigiosos, verifica checksums i prova en un entorn aïllat si tens dubtes. La desconfiança és una virtut quan es tracta de codi de tercers amb permisos totals.
També convé configurar sudoers de forma granular, no confiar només en el grup sudo per a tot i mantenir els registres auditats. Si administreu servidors, reviseu /var/log/auth.log, /var/log/secure o journalctl -xe per detectar usos indeguts. En entorns multiusuari, saber qui va executar cada ordre és clau per a la responsabilitat i per complir normatives de seguretat.
Habilitar i deshabilitar root amb cap
Si decideixes habilitar root, assigna una contrasenya amb sudo passwd root, fes-la servir només per a l'imprescindible i torna a bloquejar el compte després. Per desactivar el login directe per SSH, edita sshd_config i posa PermitRootLogin no o prohibit-password, després reinicia ssh. Per bloquejar el compte localment, suo passwd -l root. I si necessites desbloquejar-la, suo passwd -u root. Aquestes mesures redueixen la superfície d'atac i eviten atacs de força bruta contra el compte més poderós.
En la majoria de casos, la resposta pràctica a la pregunta inicial és sí: es pot llançar un programa des del launcher amb permisos de root usant un helper gràfic com kdesu, gksu, gksudo o pkexec, o creant un .desktop amb l'ordre adequada. Però no és una cosa que convingui deixar preparat per a qualsevol aplicació. És millor tenir llançadors administratius concrets, amb nom clar, i fer-los servir només quan calgui.
L'essencial és que root no és una joguina i que suo existeix precisament per donar-te poder sense convertir cada clic en un risc permanent. Si necessites arrencar una app gràfica com a superusuari, prioritza helpers que demanin contrasenya, revisa que l'aplicació realment ho necessiti i en limita l'ús a tasques administratives. Així gaudeixes de la comoditat del launcher sense renunciar a la seguretat que fa fort Linux.