Desconocimiento: ¿Por que cuando instalo un programa el root lo propaga en todas las cuentas?

18 envíos / 0 nuevos
Último envío
#1 Sáb, 24/09/2022 - 15:42
debianspirit
Imagen de debianspirit
Desconectado/a
se unió: 16/07/19

Desconocimiento: ¿Por que cuando instalo un programa el root lo propaga en todas las cuentas?

Es una pregunta de total desconocimiento de Debian, se que en Windows pasa pero no entiendo por que ocurre en los sistemas operativos e incluso yo diria que es una anomalia de todos los sistemas operativos en general que lo hacen así.

¿Se puede evitar que lo haga Debian?

 

Para resumirlo, es posible instalar un programa pero que solo se instale en un usuario en concreto y que a los demás no se le instale, por ejemplo, por seguridad o incluso integridad de la cuenta de usuario, en un sistema Debian con multiples usuario en el inicio de sesión.

 

Gracias.

Sáb, 24/09/2022 - 16:35
caliban
Imagen de caliban
Conectado
moderador
se unió: 14/01/16

Root instala una aplicacion en el sistema , root tiene permisos totales para ejecutarlo .pero por defecto

dicha aplicacion  tiene permisos de ejecución para grupos  y otros .

Si como root quitas los permisos de ejecución  para grupos y  otros , solo root podra ejecutarla.

Luego creas un grupo que incluya a tu usuario ( o a tus usuarios permitidos)  entonces incluis dicha aplicacion al grupo

y le das permisos de ejecución .

Conforme a usuarios, grupos y permisos vos podes controlar absolutamente quien ejecuta que ( o sea que aplicacion puede usar por ejemplo)

De hecho y por defecto tus archivos y carpetas tienen permisos totales cuando las creas y usas ,pero en el fondo los programas que las crean gestionan que tipo de archivo se crea,,si dichos archivos son de lectura,,o escritura,,o ambos, y quien puede escribir que, aunque para vos dichas gestiones se realizan en forma " transparente "

En definitiva lee respecto a usuarios grupos  y permisos .

Fijate como ejemplo :

ls -l /usr/bin   | tail  

Vas a ver las ultimas aplicaciones de ese directorio  , usuario grupo  permisos

Dom, 25/09/2022 - 05:15
debianspirit
Imagen de debianspirit
Desconectado/a
se unió: 16/07/19

Gracias caliban. Pero desde el punto de vista de un novato, yo :)

Te pongo un ejemplo.

Yo cuando quiero instalar algo me voy a la aplicación Software de Debian y busco lo que quiero instalar pero justo cuando voy a instalar me sale la ventana que me obliga a dar permiso de instalador con derechos de root y en ese momento que soy un simple usuario le doy la contraseña y que pasa, pues que lo instala en todos y cada uno de los usuario del pc, eso es justo lo que yo considero un error. Ya que el usuario simple instala por ejemplo con la contraseña del padre (root) y lo propaga en todos los usuarios. Debe ser un sistema algo mas elaborado para que eso no ocurra.

 

Digamos el niño instala un navegador que a nadie le gusta y por culpa de eso todos los usuario lo tienen. Por lo que tienes despues que cambiar eso el padre (root) para que la madre no se moleste ni el hermano mayor, etc.

 

Yo pienso que en el proceso de solicitud de contraseña de instalación root debe decir además es una instalación general para todos o solo para el usuario que esta activo en ese momento.

 

¿Que opinas?

 

Gracias.

 

Dom, 25/09/2022 - 13:33
caliban
Imagen de caliban
Conectado
moderador
se unió: 14/01/16

Estas considerando las cosas de forma errónea, cuando  vos haces la instalación del sistema te convertís por el mismo proceso

en administrador de dicho sistema, o sea root, luego durante el proceso de instalación te pide que ,ademas, crees un unico usuario que tendrá privilegios limitados, limitados a su /home/usuario.

Vos como usuario  tenes acceso a todas las aplicaciones del sistema a menos que el administrador lo impida ,

y las modificaciones que podes hacer sobre una aplicacion de uso general ( si se puede) siempre se limita a configuraciones personales guardadas en algun directorio dentro de /home/usuario , dichas modificaciones solo funcionan para la aplicacion dada usada por ese usuario y no para otro ,para el/los otros  si no personalizaron la configuración  trabajaran con la de uso general del sistema  y en general las modificaciones que puede hacer un usuario no dañara el funcionamiento de dicha aplicacion para el resto del sistema,o sea no pondrá en peligro la estabilidad y seguridad general .

El hecho que para poder administrar el sistema ( y por ejemplo instalar aplicaciones) te pida las credenciales de root ,es el punto de seguridad del sistema y que vos te puedas identificar como tal ,es solo un hecho casual(y causal) que sos a su vez administrador y un usuario.

Supongamos que el que instala el sistema es otra persona , vos desconoces la contraseña de administrador  y  tenes creado tu usuario del sistema. a partir de ese punto vos como usuario solo vas a poder usar las partes disponibles  y modificables a las que tenes acceso y a nada mas a menos que  root te de permisos sobre archivos, directorios del sistema ( aplicaciones ) etc.

Supongamos que vos creas tu propia aplicacion ,como usuario del sistema ,lo básico, un script , y le das permisos de ejecución,

en principio vos y solo vos podrá ejecutarlo ( y root,claro que todo lo puede)

Tambien podes instalar aplicaciones que solo estarán disponibles para ese usuario  y que no requieren credenciales de root ,

Y por cierto ,en tu ejemplo , o padre y niño son la misma persona , o el padre es un bobo que le da todas las posibilidades para que el niño haga lo que quiera en el sistema ,entonces ¿donde esta la inseguridad ,en el sistema o en un padre bobo ?

Por otra parte ,miralo desde un punto de vista mas general, que posibilidad hay que a un sistema operativo,como muchos años de uso ( ensayo y error) con una comunidad internacional que permanente y en forma constante esta a la caza de cualquier error por minúsculo que sea en cuanto a la seguridad, a nadie se le haya ocurrido que lo que vos comentas es una falla de seguridad.

No digo que un novato no pueda encontrarla,claro ,pero digo ¿que tan probable puede ser que la encuentre y sea una real falla ???

Dom, 25/09/2022 - 15:05
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

En los sistemas Linux, el directorio estándar para archivos o paquetes binarios es /usr/bin ... /usr/local/bin, es donde se guardan los binarios que no son del sistema, es decir, los paquetes compilados o mantenidos localmente ... Para un usuario específico, el directorio adecuado para él es $HOME/bin o $HOME/.local/bin.

Si instala software usando el administrador de paquetes (apt o pacman) el destino para el binario sería /usr/bin. Se sigue el estándar de la FHS (estándar de jerarquía del sistema de archivos). El directorio /usr se define como, (MULTI-)User Utilities and Applications.

/usr/local/
├── bin
├── etc
├── games
├── include
├── lib
├── man
├── sbin
├── share
│   └── man -> ../man
└── src


$ whereis gnome-terminal
gnome-terminal: /usr/bin/gnome-terminal /usr/lib/gnome-terminal /usr/share/man/man1/gnome-terminal.1.gz

Todo el software que instala usando apt o pacman, estará disponible para todos los usuarios creados en el sistema ... Supongo que la tienda de software de Gnome usa dpkg (en Debian)?

Dom, 25/09/2022 - 15:37
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Otro directorio de destino para instalar software sería /opt (aquí va el software divertido, como spotify, vivaldi, chrome, onlyoffice, etc)
Ejemplo:

$ ls -la /opt/vivaldi/
total 275688
drwxr-xr-x 2 root root 4096 sep 20 11:55 lib
-rwxr-xr-x 1 root root 274096 sep 14 11:13 libEGL.so
-rw-r--r-- 1 root root 4636328 sep 1 10:16 libffmpeg.so.5.4
-rwxr-xr-x 1 root root 6333840 sep 14 11:13 libGLESv2.so
-rwxr-xr-x 1 root root 4378512 sep 14 11:13 libvk_swiftshader.so
-rwxr-xr-x 1 root root 583024 sep 14 11:13 libvulkan.so.1
-rw-r--r-- 1 root root 6460 sep 14 11:13 LICENSE.html
drwxr-xr-x 2 root root 4096 sep 20 11:55 locales
drwxr-xr-x 3 root root 4096 ago 17 03:38 resources
-rw-r--r-- 1 root root 9689838 sep 14 11:13 resources.pak
-rwxr-xr-x 1 root root 7224 sep 14 11:13 update-ffmpeg
-rw-r--r-- 1 root root 733672 sep 14 11:13 v8_context_snapshot.bin
-rwxr-xr-x 1 root root 3126 sep 14 11:13 vivaldi

Todo el contenido pertenece a "root" ... Lo pongo de ejemplo, porque aún veo que los usuarios para lidiar con el hecho de no poder ejecutar ./vivaldi, cambian el propietario a su $USER todo el directorio de /opt/vivaldi. Mala práctica. Esto se resuelve con:

$ ls -la /usr/bin/vivaldi-stable
lrwxrwxrwx 1 root root 20 sep 14 11:13 /usr/bin/vivaldi-stable -> /opt/vivaldi/vivaldi

Dom, 25/09/2022 - 15:48
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Otro ejemplo para usar /opt ... Algunas distribuciones tienen en sus repositorios la versión Firefox-ESR ... Pero los 'millennials' desean la última versión de Firefox,


1. Go to the Firefox download page and click on the Download Now button.

2. Open a terminal and go to the folder where your download has been saved. For example:

cd ~/Downloads

3. Extract the contents of the downloaded file by typing:

tar xjf firefox-*.tar.bz2

The following commands must be executed as root, or preceded by sudo.

4. Move the uncompressed Firefox folder to /opt:

mv firefox /opt

5. Create a symlink to the Firefox executable:

ln -s /opt/firefox/firefox /usr/local/bin/firefox

6. Download a copy of the desktop file:

wget https://raw.githubusercontent.com/mozilla/sumo-kb/main/install-firefox-linux/firefox.desktop -P /usr/local/share/applications

https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-from-mozilla-builds-for-advanced-users

PD: Lo anterior es solo un ejemplo, y no es relevante para la pregunta del OP.

Dom, 25/09/2022 - 16:34
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Nunca he considerado usar más de una cuenta en mis PC's, pero a la segunda pregunta del OP, es posible ...

$ echo $PATH
/home/nikita/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/home/nikita/.local/share/flatpak/exports/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin

(1) $HOME/.local/bin -> Normalmente solo almaceno scripts aquí ... Pero nada me prohibe tener algo como, nota-v2.2.0-stable-amd64.AppImage, etc. (Verificar el hash y $chmod u+x nota-v2.2.0-stable-amd64.AppImage) ... O puedo descargar Firefox Nightly y hacer algo similar al comentario anterior (Modificar el *.desktop y enviarlo a ~/.local/share/applications - Supongo que debo crear un nuevo perfil?).

(2) Si toma el código fuente, simplemente cree el proyecto como de costumbre, pero configure el directorio de instalación para que sea /home/usr/bin ... No imagino un escenario del porque haría eso, lo siento.

(3) De la wiki Arch, "De forma predeterminada, cada comando de flatpak funciona en todo el sistema, es decir, los paquetes se instalan para todos los usuarios en la computadora y flatpak requiere que el usuario proporcione la contraseña de root. Para instalar paquetes y trabajar con repositorios para un solo usuario (sin necesidad de derechos de superusuario) puede agregar la opción --user a cada comando. Si desea, por ejemplo, agregar un repositorio que solo usted pueda ver, debe ejecutar $ flatpak remote-add --user name location. Para instalar un paquete visible solo para usted, ejecute $ flatpak install --user package-name."

Dom, 25/09/2022 - 16:45
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Finalmente no todos los *UNIX siguen la jerarquía del sistema de archivos de la FHS.

https://www.gobolinux.org/ -> SOLO PARA PERSONAS BARBONAS Y CURTIDAS EN LINUX.
https://github.com/helloSystem/hello

Lun, 26/09/2022 - 07:15 (Responder a #9)
debianspirit
Imagen de debianspirit
Desconectado/a
se unió: 16/07/19

Gracias, caliban.

Se que es un esfuerzo contestar y argumentar y te lo agradezco.

Pero te vas por las ramas.

Voy al grano. Mi cuestión es que el root es el todo poderoso y que después la instalación me pide hacer un user1, pero imaginemos tener un user2, user3.

El root y el user1 es la misma persona y digamos que instala un programa privado y que no quiere que lo tenga user2, user3, y digamos que lo hace desde la aplicación Software que como dice berbellon es de GNome, voy al grano, la aplicación Software de GNome oficial en la instalación de Debian no pide a que usuario va destinada esa instalación, solo pide la contraseña root y como ya te he dicho el root y user1 es el mismo, que menos que user1 (root) tenga la propiedad directamente en la aplicación Software de decir a quien va destinada esa aplicación y no tener que hacer una labor de root posterior, e incluso eso debe hacerse desde Software, para que el root no ande loco de aquí para ya, cuando deber ser mas simple y sintetico un sistema operativo, vamos hacer la vida mas simple y fácil al root.

 

Por favor, sigamos esta cuestión que planteo. Y no nos vayamos por las ramas.

 

Queda claro, que si esta claro, que lo que dices a mi me aclara mucho, lo que dices es que el user1 instala algo y despues hace una labor de root quitando permisos para los demás usuarios.

 

Pero estarás de acuerdo que para el root es mas cómodo que si lo instala desde la aplicación Software de GNome lo ideal sería que pida para que usuarios esta destinada esa instalación directamente y no hacer una labor de root posterior, ya que en el momento que introducimos la contraseña root el sistema ya sabe que es el administrador y debe facilitar la labor de distinguir a quien va destinada la instalación al usuario activo o a todos.

 

Espero que con esto quede al menos mas clara mis intensiones.

 

Agradezco sinceramente a ambos vuestras buenas intensiones de guiarme, gracias.

 

 

Lun, 26/09/2022 - 13:32
caliban
Imagen de caliban
Conectado
moderador
se unió: 14/01/16

Aja ,,,,

Jue, 29/09/2022 - 17:38
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

La idea no es descabellada ... Pero, Debian y Slackware son los Linux más longevos, y es muy difícil que cambien sus habitos, a corto y largo plazo (romper con el status quo, donde esta la antorcha :-) ... Para eso están las derivadas ... O las herramientas externas, como NixOS, https://nixos.org ... Y todo lo que mencione, arriba.

¿Porque manipular los permisos de los binarios?  No me gusta, nunca lo haría ... Prefiero lo anterior, véase arriba.

Repito, alguien ideo esa jerarquía en los directorios, les dio un nombre y una función ... Consideras lo que puede, o no hacer APT (léase el manual) ... Y los mantenedores de paquetes como construyen esos DEB.

<code>

$ pacman -Qlp dunst-1.9.0-1-x86_64.pkg.tar.zst 
dunst /etc/
dunst /etc/dunst/
dunst /etc/dunst/dunstrc
dunst /usr/
dunst /usr/bin/
dunst /usr/bin/dunst
dunst /usr/bin/dunstctl
dunst /usr/bin/dunstify
dunst /usr/lib/
dunst /usr/lib/systemd/
dunst /usr/lib/systemd/user/
dunst /usr/lib/systemd/user/dunst.service
dunst /usr/share/
dunst /usr/share/dbus-1/
dunst /usr/share/dbus-1/services/
dunst /usr/share/dbus-1/services/org.knopwob.dunst.service
dunst /usr/share/licenses/
dunst /usr/share/licenses/dunst/
dunst /usr/share/licenses/dunst/LICENSE
dunst /usr/share/man/
dunst /usr/share/man/man1/
dunst /usr/share/man/man1/dunst.1.gz
dunst /usr/share/man/man1/dunstctl.1.gz
dunst /usr/share/man/man5/
dunst /usr/share/man/man5/dunst.5.gz
</code>

De alguna forma APT debe mandar los binarios al directorio X, el archivo de configuración al directorio Y, y los manuales al directorio Z ... Si todo esta en su sitio, tenemos notificaciones en el sistema ... Dunst, es un programa sencillo ... Gnome-terminal, es más complejo, una configuración incorrecta en los locales, puede ocasionar que no se ejecute la terminal. 

Y que tiene que ver todo esto con la Tienda de Software de Gnome.

https://blogs.gnome.org/uraeus/2022/06/10/how-to-get-your-application-to-show-up-in-gnome-software/

Solo fragmentos,

[...] Intentaremos documentar cómo hacer esto independientemente de si elige empaquetar su aplicación como un paquete rpm o como un paquete flatpak [...]

https://gitlab.gnome.org/GNOME/gnome-software

[...] Se utiliza un sistema de complementos para acceder a software de diferentes fuentes. Se proporcionan complementos para:

Instalación tradicional del paquete a través de PackageKit (p. Ej. Paquete Debian, RPM).
Paquetes de próxima generación: Flatpak y Snap. [...]

[...] Tradicionalmente, se espera que las aplicaciones en Linux instalen archivos binarios en /usr/bin, instalen archivos de datos independientes de la arquitectura en /usr/share/ y archivos de configuración en /etc. [...]

 

No puedo instalar software en la $HOME, usando las herramientas tradicionales de Debian. Por diseño no se puede. 

 

 

 

 

Jue, 29/09/2022 - 17:53
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Y porque la contraseña ...

En alguna parte, que no voy a mencionar debe haber algo como esto,

<code>

<defaults>
      <allow_any>auth_admin_keep</allow_any>
      <allow_inactive>auth_admin_keep</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
</code>

El modo paranoico esta bien. 

[...] Permitir a los usuarios instalar paquetes sin autenticación es definitivamente peligroso.

De hecho, debido a que los paquetes de software contienen vulnerabilidades, esto podría ser abusado para obtener acceso a root, sin una contraseña. Es un poco como si sudo estuviera configurado para no solicitar una contraseña antes de ejecutar comandos. [...]

Vie, 30/09/2022 - 01:46
PabliNet
Imagen de PabliNet
Desconectado/a
se unió: 28/10/16

Desde ya que nunca utilicé Windows con varias sesiones.

No sabría cuál es la utilidad de instalar una app y/o un programa para un usuario y no para otro.

Se puede instalar una app desde un usuario normal utilizando Snap (horrible gestor de paquetes de Ubuntu).

Los gestores de paquetes «apt», «apt-get» y «aptitude» lo que hacen es manejar las app y/o programas.

Vos tenés que pensar que Linux tiene varios paradigmas distintos a los de Windows y Mac, no son mejores ni peores sino diferentes: Una misma librería es utilizada por varias aplicaciones en Linux.

Si un usuario en particular quiere instalar una app solo para él y otra para otro usuario, Linux necesitaría duplicar librerías.

Vie, 30/09/2022 - 07:05
debianspirit
Imagen de debianspirit
Desconectado/a
se unió: 16/07/19

Gracias primero a todos por el esfuerzo de guiarme ante mi gran desconocimiento de Debian.

PabliNet sin duda es muy útil usar programas individualizados por usuario. Te pongo un ejemplo. Supón que soy un gran experto de soporte en software de sistema operativo, y tengo el programa perfecto para resolver multitud de errores del sistema, cuando estos ocurran, pero tienes un hijo con su user personal para que juego o aprenda algo, el problema es que tiene una edad que le gusta tocar e investigar y abre el programa que tu tienes para reparar todo, esto en malas manos es un arma, pero en las manos adecuadas es soporte técnico.

Esto es un ejemplo, no existe y me lo pueden debatir por todos los lados, diréis que el niño no tiene la clave root para usarlo etc, etc. Y todo para tener razón, pero mi pregunta es para que es necesario ni siquiera que el niño vea esta aplicación, lo mejor sería que cuando lo instalo desde Sofware de GNome me pida es para instalación individual o para todos.

Y gracias a PabliNet que me ha dicho que si uso instalación individual se repetiría las librerías, esto es poco eficiente pero a la vez entiendo que nuevamente es un fallo del sistema que debería usar librerías y no duplicarlas para resolver algo mal.

Me temo que si es así Debian debe pensar bien un bug enorme que existe pero que lo resuelve no haciendo lo que debe. Así siempre esta bien pero no evoluciona de forma moderna. Esto es como tener un problema y esconder la cabeza en el agujero haber si así se pasa. Pero el problema esta ahí y esperando nunca se resolverá.

Debian lo ha resuelto pero simplemente no dando solución y así no da la oportunidad de tener el error.

Gracias y saludos.

 

 

 

Sáb, 01/10/2022 - 20:09 (Responder a #15)
PabliNet
Imagen de PabliNet
Desconectado/a
se unió: 28/10/16

debianspirit wrote:
PabliNet sin duda es muy útil usar programas individualizados por usuario. Te pongo un ejemplo. Supón que soy un gran experto de soporte en software de sistema operativo, y tengo el programa perfecto para resolver multitud de errores del sistema, cuando estos ocurran, pero tienes un hijo con su user personal para que juego o aprenda algo, el problema es que tiene una edad que le gusta tocar e investigar y abre el programa que tu tienes para reparar todo, esto en malas manos es un arma, pero en las manos adecuadas es soporte técnico.

Desde ya que tenés formas de evitar que otros usuarios tengan acceso a esa app o programa:

  1. Moviendo con mv el archivo /usr/share/applications/app.desktop a /home/debianspirit/.local/share/applications.
  2. Jugando con los permisos en el /usr/bin/app.

También existen entornos en tiempo de ejecución multiplataforma (Node.js) que se pueden instalar de manera local y no global.

Dom, 02/10/2022 - 12:12
debianspirit
Imagen de debianspirit
Desconectado/a
se unió: 16/07/19

Gracias, PabliNet por su info, para mi me viene genial ya que no la sabia.

Saludos.

 

Lun, 03/10/2022 - 02:52
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

No me lo puedo creer, acabas de descrubir el mayor bug en la historia de GNU/Linux, y nada menos que en una de las distros más longevas...

  No hay bar que por bien no venga....