Hola,
tencara no tenim tots els grups treballant amb Debian (demà amb sort
acabarem) i estem contents, això no treu que ja hem detectat alguns
problemes. El més important ja us el comentarem un altre dia (està
relacionat amb l'exportació de carpetes mitjançant un NFS kerberitzat, que ara es munten, ara es desmunten de manera màgica ... )

Però us volia preguntar per un possible bug que podria haver en un paquet
de postgresql.
El cas és que instal·lem la versió que hi ha per defecte a Debian 11, que és la 13 i com que a la configuració del nostre pam teníem una directiva
que obligava a root a demanar password quan feia su l'script d'instal·lació es parava demanant un password, però tant era el que escriguessis, o que en una altra terminal posessis el password a l'usuari postgres. Al final, la única manera va ser fent un kill del procès d'aquella instrucció. D'aquest amanera l'script continuava i la instal·lació acabava amb èxit.

El fitxer és
/var/lib/dpkg/info/postgresql-common.postinst

I la instrucció:



* su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
test -G /var/lib/postgresql" || \ chown postgres:postgres /var/lib/postgresql*

Vam trobar referències a: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1


Gràcies per llegir-nos,
Julio



--
______________________________________________________


-

El 2003 el català era la llengua habitual del 46 % dels catalans. Al
2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà.
-

El 3 de novembre representa el moment de l'any en el que les dones
deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a
eliminar aquesta data.
-

L’administració pública cada any es gasta milions d’euros en llicències
de programari privatiu. Utilitzant programari lliure estalviem costos i
incentivem l’economia local.

*La neutralitat davant les desigualtats acaba accentuant-les.*

<div dir="ltr"><div>Hola,</div><div>tencara no tenim tots els grups treballant amb Debian (demà amb sort acabarem) i estem contents, això no treu que ja hem detectat alguns problemes. El més important ja us el comentarem un altre dia (està relacionat
amb l&#39;exportació de carpetes mitjançant un NFS kerberitzat, que ara es munten,

On 20/9/21 23:56, Julio Amorós wrote:

Hola,
../.. a la configuració del nostre pam teníem una
directiva que obligava a root a demanar password quan feia su > ../..

I la instrucció:

*    su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
            test -G /var/lib/postgresql" || \
        chown postgres:postgres /var/lib/postgresql*

../..

Gràcies per llegir-nos,
Julio

Fins on jo se, l'usuari postgres no te password i per seguretat no n'ha
de tenir.

Potser teniu una situació impossible, el pam obliga a demanar un
password que no existeix.

No se si dir que és un bug del instal·lador postgres o una "feature" de pam.

--
Jordi Perera

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 21 septembre 2021 08:01:43 GMT+02:00, jordi Perera <zjordi_llistes@xarxa1.net> a écrit :

On 20/9/21 23:56, Julio Amorós wrote:

Hola,
../.. a la configuració del nostre pam teníem una
directiva que obligava a root a demanar password quan feia su > ../..

I la instrucció:

*    su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
            test -G /var/lib/postgresql" || \
        chown postgres:postgres /var/lib/postgresql*

../..

Gràcies per llegir-nos,
Julio

Fins on jo se, l'usuari postgres no te password i per seguretat no n'ha
de tenir.

Potser teniu una situació impossible, el pam obliga a demanar un
password que no existeix.

No se si dir que és un bug del instal·lador postgres o una "feature" de pam.

Amb Fedora teníem la mateixa situació a Pam i no es donava aquest problema i la única diferència és la versió de Postgresql.

Efectivament la 1a cosa que feiem després d'instal•lar postgresql era posar-li un password a postgres.

El que em sorprén en aquella instrucció no es tant el que demani un password, sinó perquè no ho rep i després es queixa, sembla com si alguna pipe o caràcter de escape no fes la feina des de l'script. O m'ho sembla a mi.
Vagi bé,
Julio

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola Julio,

El que em sorprén en aquella instrucció no es tant el que demani un password


Doncs és precisament això, el que em sorprèn... que demani un password. En principi, des de qualsevol shell de root hauríem de poder connectar-nos a qualsevol usuari amb shell, sense necessitat de proporcionar cap password.
I per tant, també a postgres.

L'única cosa que puc suggerir, ja que actualment no tinc gaire per la ma
això del PAM, és verificar si l'script que conté la instrucció s'executa efectivament amb els permisos de root. Potser podries provar amb la comanda
id -u dins l'script.

Espero que et serveixi.

David Gasa i Castell

Linux User #488832

<div dir="ltr"><div dir="ltr"><div>Hola Julio,</div><div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
El que em sorprén en aquella instrucció no es tant el que demani un password<br></blockquote><div><br></div><div>Doncs és precisament això, el que em sorprèn... que demani un password. En principi, des de qualsevol shell de root hauríem de poder
connectar-nos a qualsevol usuari amb shell, sense necessitat de proporcionar cap password. I per tant, també a postgres.<br></div><div><br></div><div>L&#39;única cosa que puc suggerir, ja que actualment no tinc gaire per la ma això del PAM, és
verificar si l&#39;script que conté la instrucció s&#39;executa efectivament amb els permisos de root. Potser podries provar amb la comanda id -u dins l&#39;script.<br></div><div><br></div><div>Espero que et serveixi.<br></div><div><br></div></div><div
dir="ltr" class="gmail_signature">David Gasa i Castell<br><br>Linux User #488832</div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola, Julio

... com que a la configuració del nostre pam teníem una
directiva que obligava a root a demanar password quan feia su
l'script d'instal·lació es parava demanant un password, però
tant era el que escriguessis, o que en una altra terminal
posessis el password a l'usuari postgres.

Podríeu donar més detalls de la directiva que teníeu al PAM?

El fitxer és
/var/lib/dpkg/info/postgresql-common.postinst

I la instrucció:

* su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
test -G /var/lib/postgresql" || \ chown postgres:postgres /var/lib/postgresql*

Ho he provat en un contenidor de docker i funciona perfectament,
fins i tot si li poso contrasenya a l'usuari postgres.

Vam trobar referències a: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1

Tal com comenten en aquest bug, té pinta que el problema està a
la configuració de PAM i no pas al paquet de postgresql. Si no
passava a la versió 12 pot ser per molts motius, entre els quals
també hi ha que la versió de libpam segurament també és diferent.

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmFM15cACgkQ466XjoNO Xn4LrRAAhwrGWZdfgenW4KlGHN6tyjGnezAPug9oCYG03630qopXhfUJq/kOoP0z nq76AiRea6yWFhk6cAO0B97UVxbWyOnb792QJ+IyVA4XGLX9ipL0sr/boLfs3PCs 2CZOSTR0JUAOOluIdQLX3WUtW9PzTViRYj5dyb7DpjQLvaGNV/0njuaP7UGW5waz brUCX1lSyn0ENwfxgBk5P90pcMZYGU4CVLiDL7nLqrBMsFSx4hgqhnhrUUj5rBdb LtErzA735IFULXEWSW9e08OG/QvSXqbLRyIP+CrpFubiI5DqZgfWlgWg4bpnLGSs UM2FP678Cyu4x2vOAQh3ledVuh5icBVEIMS/K5YIuZ5LiPv1RBRmZN7xF7JSg3i2 H94/qSEtZkV/mwNP+dWV6Gxag4443UzNUTB6LiUoMBOmnIWHLjw5iuawkpcTPFKb J5bkakaQtp2+DfJuK7dAXZZ/8qusVzpoXo3lz+vMgaODsGVu0d5AuC5aW3skqenH rgHBo9jF4wakZX40WO1N/j5k2e7gyl2qtlrFQtingQ4OEFHlZ9RFCo6lcYqTHKux f/jdLo7KCE25IRzRLQf1bHRg4Fejy7IqhgTIr3yOvftp3NJ7y1wb89ibh1dwlrEk iHSgeehXjeSTWAMfYjivR+S7nWG3VqEuDzsF1XqFLmzkOgSm09I=
=wGTq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

------DFIBN1CX2PG3B0AHWHXGBHARX4VYZB
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hola Àlex,
la directiva del fitxer
/etc/pam.d/su
és
# auth sufficient pam_rootok.so

Si la descomentem el postgresql funciona.bé, ja que lògicament ja no demana el pass, però llavors tenim un "forat" pel ticket de kerberos :)

...

Has de descomentar la 2a línia.
S'entèn?

Le 23 septembre 2021 21:38:09 GMT+02:00, Alex Muntada <alexm@debian.org> a écrit :

Hola, Julio

... com que a la configuració del nostre pam teníem una
directiva que obligava a root a demanar password quan feia su
l'script d'instal·lació es parava demanant un password, però
tant era el que escriguessis, o que en una altra terminal
posessis el password a l'usuari postgres.

Podríeu donar més detalls de la directiva que teníeu al PAM?

El fitxer és
/var/lib/dpkg/info/postgresql-common.postinst

I la instrucció:

* su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
test -G /var/lib/postgresql" || \ chown postgres:postgres
/var/lib/postgresql*

Ho he provat en un contenidor de docker i funciona perfectament,
fins i tot si li poso contrasenya a l'usuari postgres.

Vam trobar referències a:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1

Tal com comenten en aquest bug, té pinta que el problema està a
la configuració de PAM i no pas al paquet de postgresql. Si no
passava a la versió 12 pot ser per molts motius, entre els quals
també hi ha que la versió de libpam segurament també és diferent.

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------DFIBN1CX2PG3B0AHWHXGBHARX4VYZB
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>Hola Àlex,<br>la directiva del fitxer<br>/etc/pam.d/su<br>és<br># auth sufficient pam_rootok.so<br><br>Si la descomentem el postgresql funciona.bé, ja que lògicament ja no demana el pass, però llavors tenim un "forat"
pel ticket de kerberos :)<br><br>...<br><br>Has de descomentar la 2a línia.<br>S'entèn?<br><br><div class="gmail_quote">Le 23 septembre 2021 21:38:09 GMT+02:00, Alex Muntada &lt;alexm@debian.org&gt; a écrit :<blockquote class="gmail_quote" style="
margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">Hola, Julio<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">... com que a la configuració del nostre pam teníem

Hola, Julio

la directiva del fitxer
/etc/pam.d/su
és
# auth sufficient pam_rootok.so

Si la descomentem el postgresql funciona.bé, ja que lògicament
ja no demana el pass

Confirmo que comentant la directiva em passa el mateix que a
vosaltres. Instal·lant dialog em surten els menús de curses per
pantalla però la contrasenya no es pregunta amb dialog i per tant
no funciona bé. Se m'acuden diferents opcions a explorar:

- potser cal tenir instal·lat o activat algun altre component que
integri dialog o el que toqui amb el su
- millorar l'script de postinst de postgres perquè utilitzi algun
altre mecanisme per canviar a l'usuari postgres
- instal·lar el postgresql abans de desactivar el pam_rootok

però llavors tenim un "forat" pel ticket de kerberos :)

No tinc experiència amb kerberos i no acabo d'entendre això.
Vols dir que desactivar el pam_rootok és un requisit per a tenir
kerberos?

Tenint en compte que root pot afegir fàcilment aquesta directiva
un altre cop al fitxer /etc/pam.d/su, no tinc clar què es resol
comentant-la (tret que no permetis que root editi aquest fitxer,
és clar).

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmFN9ZoACgkQ466XjoNO Xn57lxAAs5PjqRh9mZRxFWf4EAt5lsUXalMBkFyBzITGOryUkli1/QJbSMYGq5SX T4C//qA4hnOXr9BV/JQd4M9A8as85QV+a5nu+aaCL8NB3iFwmFVIUwSQwtqdB63m z1aBNI40Sk5fQH5vKnWBY6nnVQPMUnSUtCshYWwIK7i8DOAz1b4sZEHzHENn4qXY lrWrBsWHhOvwuuTkhi5IEEDNzsfGf00vlhr8BfZ1WvabR+61f4H7E2MJLZ5H34zQ 0CbXW8VDv6NaPvmtIoNHPohvZmZ4I48M6qwysByRkuAuixm8g44fC6LQukstUopq U2FjJcV1CblRb0pKfwB+pg3zE1KN8mUrMvSb8KC5j0AP6F7J0kl1FD5+wTxK2ZNW BYSWl38lmEW0VeSdKicabZoAKv9rei7G0Qlj/dUTmwmypUm8j0qZEy+QvrLoEmxZ FObGYwRmoHoGe/zYaGrTFj56Pr2WCFt5e64OfrFR/uRGk4tv/X+4OhOjanDXMjDK YfatbXHgfuDYMs5aBa5BU4iPQEdYTemlwx7Pdz4tOv0g07PcfyDHhoj3HwjOCf53 mGT/T7Rg2e5glcFrk69QZMnI7IEkcbkDHcjCUh0EVkAOSm9g634LEoPi++DYGKc4 P00gHYfJa0ikKceVp73SBSj2A9poxWA1S1L8/vEqKLQWvqAAHJM=
=o+lW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Escric ràpid i de memòria perquè tinc poc temps ara mateix, intentaré documentar la resposta millor quan pugui...

El 24/9/21 a les 17:58, Alex Muntada ha escrit:

[...]

- millorar l'script de postinst de postgres perquè utilitzi algun
altre mecanisme per canviar a l'usuari postgres

Acabo de recordar que fa un temps (oldstable o fins i tot oldoldstable)
hi va haver un canvi important a la comanda su, bàsicament hi havia dues implementacions i es va canviar d'una a l'altra per defecte, que tenia
algunes subtileses. Crec que es va documentar a les release notes corresponents, a veure si quan pugui ho trobo i ho enllaço.

Una de les recomanacions que vaig llegir aleshores era usar la comanda "runuser" quan qui l'executa ja és root, doncs desescala a qualsevol
usuari sense demanar autenticació mentre que la resta d'usuaris no la
poden executar.

No tinc clar si funcionaria en aquest escenari específic que s'ha
descrit ni si la presumpció que els postinst s'executen amb permisos de
root és sempre certa, per tant no puc valorar si el canvi de su a
runuser seria una solució adequada per al paquet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola, Eloi

Acabo de recordar que fa un temps (oldstable o fins i tot
oldoldstable) hi va haver un canvi important a la comanda su,
bàsicament hi havia dues implementacions i es va canviar d'una
a l'altra per defecte, que tenia algunes subtileses. Crec que
es va documentar a les release notes corresponents, a veure si
quan pugui ho trobo i ho enllaço.

Jo també ho recordava però només he trobat aquest petit comentari
a les notes d'alliberament de Debian 10 (he remuntat fins a la 8,
no he mirat més enrere):

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#su-environment-variables

«su has changed semantics in buster and no longer preserves the
user environment variables DISPLAY and XAUTHORITY. If you need to
run graphical applications with su, you will have to explicitly
set them to allow access to your display. See bug #905409 for an
extensive discussion.»

Una de les recomanacions que vaig llegir aleshores era usar la
comanda "runuser" quan qui l'executa ja és root, doncs desescala
a qualsevol usuari sense demanar autenticació mentre que la
resta d'usuaris no la poden executar.

Això no recordo haver-ho llegit però ho acabo de provar i
funciona bé: no demana contrasenya encara que comenti l'entrada
del pam_rootok al /etc/pam.d/runuser.

No tinc clar si funcionaria en aquest escenari específic que
s'ha descrit ni si la presumpció que els postinst s'executen
amb permisos de root és sempre certa, per tant no puc valorar
si el canvi de su a runuser seria una solució adequada per al
paquet.

Vist que tant su com runuser pertanyen a util-linux, trobo que
seria una bona idea suggerir als mantenidors del postgresql que
utilitzin runuser enlloc de su per a fer les comprovacions del
postinst. En aquest sentit, crec que la millor manera de fer-ho
és obrir un bug.

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmFO5pQACgkQ466XjoNO Xn7+fw//WFYU7xbE7LW1OU5zB7BwC8N9U+Us29ertRka8m3kryHM78ymH6DjPHJ8 nWp76MUIDXPLHZJNRkflJz2uoZ0mjrD+Rb3QRL30+XYV6Kxe3pGovDpT7V6ZhFEd OwDR84R/4fIIQf5IvpLy3d2gPmmyNNIVekCOdCdiWViaEs1fD/d4FwtuOXc6Hgal CEAss+6rC73LaOk7sf9z9as+Pso0Hug7CTVJrWd7Ey/aPgUfTp7sFkeNcJ8RvhUp V3iRbRVlbcdQzU6tbVSrToHZt8UCzmCz2ChdJa2em6/vLUg8yAJ5Dn4YYAu5pRJE 1SzlTQlzA0SGcNKqXrPxkE3IeVMNnrfvWAo/yOhCa1gvqZ63cXNbrrJAh3y+yqUN RdM5VSuinL7sCNaQkeiRNWtdyJf08E4NNwd43y+1Z6HUVl4iO12CFkH+KxG0uGiJ lrkktkZW6/qdC2c3YebeKGlWBD1sioBkEK7BUKaIE7BcR33pJUCt5bX8+z5AdeGI JYqxcdB3A4tJoTE8scLjfGkIraEiVCFHYGtviSqQc0VWuRIMZYa1yoEzvYUJwL4o oeWNbwsaX+5Mv2EYF68MvR1SoSLakHZxXta4hdom/aHRFGEsS8+Vzr1LEWu2terP 7RSS0wldJYA++p/4yZjJSDnBAyRWt+wNIX+uvaaOdG/v/OGBCXo=
=fUYe
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 25/9/21 a les 11:06, Alex Muntada ha escrit:

Hola, Eloi
[...]

Una de les recomanacions que vaig llegir aleshores era usar la
comanda "runuser" quan qui l'executa ja és root, doncs desescala
a qualsevol usuari sense demanar autenticació mentre que la
resta d'usuaris no la poden executar.

Això no recordo haver-ho llegit però ho acabo de provar i
funciona bé: no demana contrasenya encara que comenti l'entrada
del pam_rootok al /etc/pam.d/runuser.

Això és que em faig vell i/o no menjo prou cues de pansa :-)

Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser
una font de tercers, que em deuria enganxar documentant-me i al final he
acabat confonent els orígens. L'única referència explícita que he estat capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins
debian.org és la següent, que no és el que recordo haver llegit però que igualment apunta en la mateixa direcció:

https://bugs.debian.org/890862

Si trobo on redimonis vaig llegir-ho us ho faré saber.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------cc416f4a0806d9d82e05e04f6018baef Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Al man su/man runuser hi fa alguna referència. Però no entenc el motiu perquè és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir kerberos).

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

El dissabte, 25 de setembre 2021 a les 21:00, Eloi <entfe001@gmail.com> va escriure:

El 25/9/21 a les 11:06, Alex Muntada ha escrit:

Hola, Eloi

[...]

Una de les recomanacions que vaig llegir aleshores era usar la

comanda "runuser" quan qui l'executa ja és root, doncs desescala

a qualsevol usuari sense demanar autenticació mentre que la

resta d'usuaris no la poden executar.

Això no recordo haver-ho llegit però ho acabo de provar i

funciona bé: no demana contrasenya encara que comenti l'entrada

del pam_rootok al /etc/pam.d/runuser.

Això és que em faig vell i/o no menjo prou cues de pansa :-)

Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser

una font de tercers, que em deuria enganxar documentant-me i al final he

acabat confonent els orígens. L'única referència explícita que he estat

capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins

debian.org és la següent, que no és el que recordo haver llegit però que

igualment apunta en la mateixa direcció:

https://bugs.debian.org/890862

Si trobo on redimonis vaig llegir-ho us ho faré saber.

-----------------------cc416f4a0806d9d82e05e04f6018baef--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsFzBAEBCAAGBQJhT3doACEJEKY//znfwr7DFiEElHcg43QoEJtv65irpj// Od/CvsOY4g//SBuynso4aTuPzCSPOoudS29uVh0+r5+bte5k6RGsG0Qichgj u+YlFEIoTSfJCWWTrzCVd+aziWBtG2knZLfz1EYBOO9dbz0eNaC7w3QbWUsQ l/zFkzg6MkbQ/A/C6OP0RCzCeSDylDXRfQ3oztfIAc+/OAXV0BKe8OKtXMHF CGhN1mn+XKIchHXp9RQ0BE7Th1ITBwl6CpXx3czEFotOHhGvEA4W4sIfsjI0 5a5Tg84p9PEIP+yma9Ao+1VBMIhvlRpGHA1E2t2E5g/2UuoPBy+A5sS9iliS wDugfz0W7/jXz8/s0PybGUydM/4Rv9ns2tuRvKwNYPFUpZ2tFzbG7v//AiVv 3pz6J0uFu6FCzYRsWewlKP0fd59cdSxztFoN/Qd6oe4TN+dFwMSjW5E/nyX8 dSmjjQzBH23ft2onfhzBFJxAyzTda5OAFXA5TS8TNDbeby8/gQenbZRQuSLx 6TRpujZkFYvA3rpl1xatZgugKEJyNqw6XLHO3wSxNzaEhjHiWxdJ/FikxXDJ w+4rXSFQNVSShNinxJIsQuUxuqjAXFgkhbM8lEUiI3QSNH/CzJ3bdl0D42GS glkvfriYmGOgn2ML2P6itbAqvCHXn7K0C3b6XjwHdSfFJIhHMYHPsyBmlmnC wMiqm/Pc/8jSdJpmq/sY2rEZPoLUVITsPvo=
=/zRW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola,
molt interessant la conversa, com sempre.
Tens raó Àlex, això forma part d'una configuració extra que afegim (la línia comentada del pam) per tant efectivament si algú té curiositat ... :) I Toni, el problema amb Kerberos, és que si no fas un kdestroy o l'elimines manualment de /tmp dura no se quantes hores i per tant amb l'ordre que hem esmentat pots fer ...
Potser això també és configurable per a que quan un usuari tanqui la seva darrera sessió s'elimini aquest ticket ¿?
De fet pensàvem provar-ho manualment a alguns ordinadors posant-ho al
logout (si nomes hi ha una sessió d'aquest usuari => kdestroy) però vaja
...
Merci,
Julio

Missatge de Toni Mas Soler <antomassol@protonmail.com> del dia ds., 25 de
set. 2021 a les 21:26:

Al man su/man runuser hi fa alguna referència. Però no entenc el motiu perquè és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir kerberos).

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

El dissabte, 25 de setembre 2021 a les 21:00, Eloi <entfe001@gmail.com>
va escriure:

El 25/9/21 a les 11:06, Alex Muntada ha escrit:

Hola, Eloi

[...]

Una de les recomanacions que vaig llegir aleshores era usar la

comanda "runuser" quan qui l'executa ja és root, doncs desescala

a qualsevol usuari sense demanar autenticació mentre que la

resta d'usuaris no la poden executar.

Això no recordo haver-ho llegit però ho acabo de provar i

funciona bé: no demana contrasenya encara que comenti l'entrada

del pam_rootok al /etc/pam.d/runuser.

Això és que em faig vell i/o no menjo prou cues de pansa :-)

Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser

una font de tercers, que em deuria enganxar documentant-me i al final he

acabat confonent els orígens. L'única referència explícita que he estat

capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins

debian.org és la següent, que no és el que recordo haver llegit però que

igualment apunta en la mateixa direcció:

https://bugs.debian.org/890862

Si trobo on redimonis vaig llegir-ho us ho faré saber.

--
______________________________________________________


-

El 2003 el català era la llengua habitual del 46 % dels catalans. Al
2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà.
-

El 3 de novembre representa el moment de l'any en el que les dones
deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a
eliminar aquesta data.
-

L’administració pública cada any es gasta milions d’euros en llicències
de programari privatiu. Utilitzant programari lliure estalviem costos i
incentivem l’economia local.

*La neutralitat davant les desigualtats acaba accentuant-les.*

<div dir="ltr"><div>Hola,</div><div>molt interessant la conversa, com sempre. <br></div><div>Tens raó Àlex, això forma part d&#39;una configuració extra que afegim (la línia comentada del pam) per tant efectivament si algú té curiositat ... :)</

<div>I Toni, el problema amb Kerberos, és que si no fas un kdestroy o l&#39;elimine

Hola, Julio

el problema amb Kerberos, és que si no fas un kdestroy o
l'elimines manualment de /tmp dura no se quantes hores i per
tant amb l'ordre que hem esmentat pots fer ...

No entenc quina relació té l'expiració de sessions de kerberos
amb el fet de no permetre que l'usuari root executi el su que
vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva
pàgina de man, he vist que també hi ha setpriv, que ni tan sols
utilitza pam.

Ens pots explicar amb una mica més de detall el problema de fons?

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmFXf4YACgkQ466XjoNO Xn7YtxAAz3j9gFePADcW2Gw8Dsuz768l4VrkuXAzjVWMBE2yVQfXh/SG4zvS3iaD xgofaqAYpHlF+D/FROpu9bPuPSKlD9e9hNv8RU7SsFmZjXy22lxA9HiCHNp1QSLQ LPyc1hyGa9V/O59I/afwG6htYbypDsZZ1QvK/qeR+7U9ZtjplIdyVieCdTJuWf2j gqiNaAVtEq4PDJMyUYBKZtqDDbZzXeiggsHe1Yj3C6I6ItGuHHoKrHm+1zuakLTw 3UWJzInQN3VjYiHXYnfWFcaTMXqpwVoGueWor7a63erW28AZG+MohIJ3azRqBKgr 1YRGxvjdKxAuM+FeQHPONW22wfJ12J7enBkNXl/LxpQ5omTOgwLj2Oo+l1orU9Po pFy3M5cTal0qiqtcbMq5VmpZ/2goBYKlQVNr5o/ZY5YDBd7BKblic0gU9ZUMlyFu pvVlLhK19D6BtkHRC9LipH5xlcsAraOXlPqa/or3IVqVvci7DpVnmCEO7ubr+7Be L+Cn24zJWD9Ljz7sp2cpLa1nNxkhKzeOiGnjbMiMc9ROt7Jnh5FdZZreUreSHotT jwXEnqmEh3CbwW++oHOVS1P6k7ybUaLvdkTW+XAryR3jZBqvE5EFGSK4UrJn17Ng 3yX1gV+YUQnrynev0IjuJnkrx6MJnfNxZe7klG/obAxj5WWlMLw=
=0tog
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Missatge de Alex Muntada <alexm@debian.org> del dia dv., 1 d’oct. 2021 a
les 23:37:

Hola, Julio

el problema amb Kerberos, és que si no fas un kdestroy o
l'elimines manualment de /tmp dura no se quantes hores i per
tant amb l'ordre que hem esmentat pots fer ...

No entenc quina relació té l'expiració de sessions de kerberos
amb el fet de no permetre que l'usuari root executi el su que
vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva
pàgina de man, he vist que també hi ha setpriv, que ni tan sols
utilitza pam.

La idea és:
- els usuaris del grup A fan servir els seus ordinadors amb un compte
ordinari ( contra un ldap+kerberos) i amb el compte root local.
- els usuaris del grup B no han de fer servir el seu compte als ordinadors
del grup A, i ja estan avisats, però sempre hi ha algun despistat.

Quan un d'aquests despistats del grup B, es logueja i s'oblida de fer
kdestroy, el tiquet de kerberos roman durant unes hores a l'ordinador i en aquest moment, qualsevol usuari amb el compte local de root pot fer un `su
-l usuari_despistat_del_grup_B`

No sé si m'explico :)

Julio


--
______________________________________________________


-

El 2003 el català era la llengua habitual del 46 % dels catalans. Al
2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà.
-

El 3 de novembre representa el moment de l'any en el que les dones
deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a
eliminar aquesta data.
-

L’administració pública cada any es gasta milions d’euros en llicències
de programari privatiu. Utilitzant programari lliure estalviem costos i
incentivem l’economia local.

*La neutralitat davant les desigualtats acaba accentuant-les.*

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Missatge de Alex Muntada &lt;<a href="mailto:alexm@debian.org">alexm@debian.org</a>&gt; del dia dv., 1 d’oct. 2021 a les 23:37:<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,

Malauradament limitar l'ús de su no és suficient per evitar que
un usuari amb root es pugui convertir fàcilment en un altre o
executar ordres en nom d'un altre: a banda del runuser i setpriv,
qualsevol llenguatge de programació prou genèric permetrà cridar
les funcions del sistema per fer-ho sense passar pel PAM.

Cert.

Se m'acut que la millor forma de què els alumnes tinguin root
però no interfereixin amb d'altres usuaris és que tinguin una
màquina virtual per cadascú.

Segurament Àlex, però som de la filosofia de que facin servir sistemes reals i que els trenquin, com a sistema de capçalera, evidentment també fan servir VMs i Dockers.
El problema realment és que es loguegin a una màquina on algun despistat ho hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori d'aquest usuari despistat.
Potser el que s'hauria de fer és permetre la exportació de segons quins directoris a segons quines IPs...
Merci per les bones idees.
Julio

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hola, Julio

Quan un d'aquests despistats del grup B, es logueja i s'oblida
de fer kdestroy, el tiquet de kerberos roman durant unes hores
a l'ordinador i en aquest moment, qualsevol usuari amb el compte
local de root pot fer un `su -l usuari_despistat_del_grup_B`

Això és el que sospitava, gràcies per explicar-ho amb detall.

Malauradament limitar l'ús de su no és suficient per evitar que
un usuari amb root es pugui convertir fàcilment en un altre o
executar ordres en nom d'un altre: a banda del runuser i setpriv,
qualsevol llenguatge de programació prou genèric permetrà cridar
les funcions del sistema per fer-ho sense passar pel PAM.

Se m'acut que la millor forma de què els alumnes tinguin root
però no interfereixin amb d'altres usuaris és que tinguin una
màquina virtual per cadascú.

Salut,
Alex

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Alex Muntada <alexm@debian.org>
⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org
⠈⠳⣄⠀⠀⠀⠀


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEaUBwKsbetWW2SKTt466XjoNOXn4FAmFaA2oACgkQ466XjoNO Xn7SMA/+JTQkLliAvtxovg44VN4mV+Fx2aCjEs0VxYG1yOuXUv6fW4hlcQFXlW86 08X6jZlx0OzC/aWLJ48tyRO+mmia/Z3uO5YvLZ/xLwG7jvmGZvQZ2CWAaXyqQXbU lvjvaMBobHYdbR/y+tO0izwLmjdFcJDO/QsPGhQxUIlHwoMrvaf/ra676tevBqKJ T0XFcD50imfrehhEoSZtRSoju/J8xwC5FDtR6jkZYOOYxmRftIIWPOxv4kL9x80M 74u19R5A1P+Z/2K4vCRODPoJf6vQCZme4zXTBlvMoSbRaSt4Drf59gX3Z+jlnad4 RIhMmPnUdKpS/tL7iAD76tR1iNHffqDNhBNn6VXH7QAZWlWyPYUH2zamHZyId/YG /rCk1jXt54kXWrGGI3KZ6oIq5Dblx5o2pAVTYGLJqQD3Fyrjzae6kQLUutWcjPA6 1TmsGla8sn0MXWzsHOnqoz5zc02LOoDS/DcpXF0x7w3WOzEIFHExxn+w6wVAYkTV LfQiBJb8BcAEcNfO5KNZaqAdRtQa95jn5JhRNgtGJ9lOILVoB8BXzdCWPxPa0/f6 mNCFlE6YZrsh2PT1FubJnlAWRNy3n7JHcw25j8NQhBP6+KdqXZiVhL+sWgIl+zFz VMyIxJpyHJIdmrcuVY79I0Rq9IflKWCBVNvAWZjSgyqP5rKyuwY=
=JcZG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------a2925b8fb2746a6c0f4f5010fd00fd84 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Moltes gràcies per l'explicació.

Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

El diumenge, 3 de octubre 2021 a les 21:43, julio <jamoros@correu.escoladeltreball.org> va escriure:

Malauradament limitar l'ús de su no és suficient per evitar que

un usuari amb root es pugui convertir fàcilment en un altre o

executar ordres en nom d'un altre: a banda del runuser i setpriv,

qualsevol llenguatge de programació prou genèric permetrà cridar

les funcions del sistema per fer-ho sense passar pel PAM.

Cert.

Se m'acut que la millor forma de què els alumnes tinguin root

però no interfereixin amb d'altres usuaris és que tinguin una

màquina virtual per cadascú.

Segurament Àlex, però som de la filosofia de que facin servir sistemes reals i que els trenquin, com a sistema de capçalera, evidentment també fan servir VMs i Dockers.

El problema realment és que es loguegin a una màquina on algun despistat ho hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori d'aquest usuari despistat.

Potser el que s'hauria de fer és permetre la exportació de segons quins directoris a segons quines IPs...

Merci per les bones idees.

Julio

Salut,

Alex

--

⢀⣴⠾⠻⢶⣦⠀

⣾⠁⢠⠒⠀⣿⡁ Alex Muntada alexm@debian.org

⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org

⠈⠳⣄⠀⠀⠀⠀

Sent from my Android device with K-9 Mail. Please excuse my brevity.

-----------------------a2925b8fb2746a6c0f4f5010fd00fd84--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsFzBAEBCAAGBQJhWtFTACEJEKY//znfwr7DFiEElHcg43QoEJtv65irpj// Od/CvsO3NA//V21ozZrDmSMJ1k705cstsaktVUYhCRynRUmIna4HyQqJzFmk YERlaccOUR6eTKyimmdVELt3f5cqDtiu6gFVTgu/9kjRlJR3qwt/ZqBbkIq/ KA+huy6UQW8reVsHYkQpy9zO6dU1jg9NTfztGQxPPxxko8MZSVMpZgTIO453 6DK1Yajz4cz+XyqGexn/v9e+ORIsqVo1y6/RaOuukpeS9HYfkLE+V+upHX8Z aBVvNB0aUZFwB4VtcHl7Ap3CZ09HY9xMZDIIlOKMDH+vaPoUxYdCsthFSYcs xk6hYe1rMfyfILamah4NHBbqD0Xo6DxwRmHX1BmjlVbabXl2Yry3DQQjYb01 R/FR7t2dC/jmvMkvvzEh87PoPZGfYqES7q6qVHN/ItmXY3mhA8CdwOV4i+/b KHcNli229IgFwwqybXqvNqgrwAgPmNZJDx6Z760V3XoMfNiFIkJQPsG5EFSX RhKlQxVs53UZSAxg2yHrjM1G2FKeGO7llYcF38FNq8JVVci+vFSjXXkpS0kK zOKLP7J8ekYWt/d0pQJcK+DK8cjOxvbvWo/fqZEOHj0wI4A/TaK5ZlwsD9uU GAaVtzN+n0ipsr8KOpf5aIFa55YCR4xWLHXNd59g7vq6nhDLRMOEFdNGBtIY 0eITL5bgE4ZWYeqeiWTVIiP3ug7Xpk1XBPc=
=gKTS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)