Re: (deb-cat) sudo as lp
És que, en aquell ordinador en concret, havent resolt el tema d'AppArmor s'ha resolt tota la resta; ni tan sols cal fer servir «sudo» perquè no hi ha problema de «too many files...». La següent batalla serà veure perquè am Debian 8 (stable) sense la presència d'Apparmor les interfícies-script configurades així a CUPS ni tan sols s'arriben a executar. __ I'm using this express-made address because personal addresses aren't masked enough at lists.debian.org archives. El 16/09/16 a les 18:30, Alex Muntada ha escrit: > Narcis Garcia: > >> Ambdues instruccions al programet (després d'intentar l'execució >> remota...too many files...): >> lsof -p $$ > /tmp/lsof.$$ >> strace -f -e open Epson1 > /tmp/strace.$$ >> Produeixen els fitxers: >> /tmp/lsof.5618 >> /tmp/strace.5618 > > Només un petit apunt sobre això: l'ordre strace l'has d'executar > des de fora del programa que vols avaluar i el paràmetre Epson1 > havia de ser el camí sencer a /etc/cups/interfaces/Epson1 perquè > no està al PATH (no vaig posar-lo sencer perquè no el recordava). > > Prova a fer «strace -f -e open /bin/ls» per veure què fa (no cal > fer-ho com a root). > > Salut, > Alex >
Re: (deb-cat) sudo as lp
Narcis Garcia: > Ambdues instruccions al programet (després d'intentar l'execució > remota...too many files...): > lsof -p $$ > /tmp/lsof.$$ > strace -f -e open Epson1 > /tmp/strace.$$ > Produeixen els fitxers: > /tmp/lsof.5618 > /tmp/strace.5618 Només un petit apunt sobre això: l'ordre strace l'has d'executar des de fora del programa que vols avaluar i el paràmetre Epson1 havia de ser el camí sencer a /etc/cups/interfaces/Epson1 perquè no està al PATH (no vaig posar-lo sencer perquè no el recordava). Prova a fer «strace -f -e open /bin/ls» per veure què fa (no cal fer-ho com a root). Salut, Alex
Re: Dubtes sobre instal·lació de paquets específics de Sid.
Robert Marsellés: > Això ho he llegit a molts llocs però són paquets dels repositoris > "contrib" + algun de "non-free" i no sé si això fa augmentar aquest risc > de mala sort. A més a més, cada cop que s'actualitza VirtualBox, també > ho fa el mòdul pel nucli Linux. Usant el sistema de paquets de Debian > tota aquesta feina es fa sola. Que és el gran avantatge que hi veig i > pel que estaré eternament agraït als desenvolupadors voluntaris que fan > aquesta feinada de "xinos" d'enllaçar dependències (perdoneu per > l'expressió). Crec que en Jordi es referia a la meva proposta d'instal·lar els .deb a mà no a la que feia d'instal·lar el VirtualBox original. Amb la solució que en Jordi ha comentat, crec que utilitzar els paquets és l'opció més senzilla. D'altra banda, a virtualbox.org diuen que l'instal·lador genèric per a tots els linux no té dependències fortes perquè es genera amb una EL5, que té versions força antigues i encara disponibles en moltes distros. Tot i així, no ho he provat i estic d'acord amb tu que utilitzar els paquets de Debian és millor en molts sentits. > "Manualment"? Ja era manual l'exemple que vaig ficar. Més manual encara? > Què vols dir? (enteneu ara lo de ser curiós? Se m'escapa. No fa falta > que contestis faré servir la versió automàtica del Jordi) Volia dir que localitzis el paquet que t'interessa en un mirall qualsevol, el descarreguis i l'instal·lis amb «dpkg -i *.deb». És a dir, més manual encara ;) Aquest mètode té la pega que no comprova la signatura digital del paquet, per això cal anar amb compte. > El gestor que uso és "aptitude". He vist al "man" que també té l'opció: > -t . Ho provaré així. Diria que l'aptitude també llegeix la configuració dels fitxers apt.conf* però si vols assegurar-te que no trenques res, potser vols provar a dir-li també l'opció -d perquè descarregui els paquets però no els instal·li, o l'opció -s perquè simuli les operacions i prou. Salut, Alex
Re: Dubtes sobre instal·lació de paquets específics de Sid.
Jordi Mallach: > En lloc de fer-ho manualment, es pot fer amb apt: > > cat > /etc/apt/apt.conf.d/default-release.conf << EOF > APT::Default-Release "stretch"; > EOF Oh! Això és genial :) Salut i moltes gràcies! Alex
Re: Dubtes sobre instal·lació de paquets específics de Sid.
Hola a tots,
Primer, moltíssimes gràcies per les suggeriments. Simplement aclarir que
jo no obligo a ningú a fer, instal·lar-se, ni subscriure's rés ni en lloc.
Al contrari, és a mi que m'exigeixen usar aquesta eina. I si algun cop
he proposat alternatives el més simpàtic és queixa, els més radicals
escullen algú altre per fer la feina dient que jo els "calentava" massa
el cap.
On 16/09/16 09:04, Jordi Mallach wrote:
>
> El que proposa l'Àlex és el millor.
>
> Normalment, si no tens la mala sort de que el paquet que vols
> instal·lar està immers en una transició (https://release.debian.org/tra
> nsitions/), els paquets de sid s'instal·len en testing sense problema.
>
Això ho he llegit a molts llocs però són paquets dels repositoris
"contrib" + algun de "non-free" i no sé si això fa augmentar aquest risc
de mala sort. A més a més, cada cop que s'actualitza VirtualBox, també
ho fa el mòdul pel nucli Linux. Usant el sistema de paquets de Debian
tota aquesta feina es fa sola. Que és el gran avantatge que hi veig i
pel que estaré eternament agraït als desenvolupadors voluntaris que fan
aquesta feinada de "xinos" d'enllaçar dependències (perdoneu per
l'expressió).
Jo aprenc de forma autodidacta provant poc a poc. Tot de cop ...
m'esgarrifa una mica i és el que m'ha frenat aquest cop. Si fos
qualsevol altre paquet ni tan sols us hagués preguntat. Ja estaria provat.
> El dj 15 de 09 de 2016 a les 15:54 +0200, en/na Alex Muntada va
> escriure:
>> Com que testing i unstable no s'allunyen excessivament, per què
>> no proves d'instal·lar el .deb de unstable directament? Sense
>> l'apt, vull dir. Com a molt et tocarà instal·lar manualment
>> alguna dependència i prou.
"Manualment"? Ja era manual l'exemple que vaig ficar. Més manual encara?
Què vols dir? (enteneu ara lo de ser curiós? Se m'escapa. No fa falta
que contestis faré servir la versió automàtica del Jordi)
>
> En lloc de fer-ho manualment, es pot fer amb apt:
>
> cat > /etc/apt/apt.conf.d/default-release.conf << EOF
> APT::Default-Release "stretch";
> EOF
>
> cat > /etc/apt/sources.list.d/sid.list << EOF
> deb http://httpredir.debian.org/debian sid main contrib non-free
> EOF
>
> apt update
> apt install -t sid virtualbox virtualbox-qt virtualbox-dkms
>
El gestor que uso és "aptitude". He vist al "man" que també té l'opció:
-t . Ho provaré així.
> Amb això hauries de poder instal·lar el virtualbox de sid i potser
> alguna dependència extra en el pitjor dels casos, sense fer-ho a mà.
> (disclaimer: no ho he provat, però hui m'he alçat optimista :D)
>
Vinga, jo també.
> Una vegada el vbox entre en testing, ja no tindràs res amb la versió de
> sid, i tot normal.
>
Si ho he entès bé, al primer fitxer "default-release.conf" deixo clar el
repositori que vull seguir ("testing") mentre que al segon especifico
l'adreça del repositori "unstable" per si mai necessito rés d'allí.
Correcte?
A més a més, així no he de canviar rés del fitxer /etc/apt/sources.list.
Quan el paquet a "testing" passi a una versió major que el que tinc de
"unstable" l'usarà i tornaré a estar com al principi.
Aquesta era la idea que jo tenia al cap però que no sabia com
implementar. Algun cop ho havia provat a mà. Hi tenia adreces de
diferents repositoris i anava (des)comentant les que m'interessava. Em
sembla més civilitzada i clara la teva manera.
De nou, moltes gràcies. Ja us diré com va. Abans vull fer una ullada als
manuals de apt.conf (5) i sources.list (5).
Salut i peles,
robert
Re: (deb-cat) sudo as lp (resolt)
El 16/09/16 a les 11:44, Narcis Garcia ha escrit: > El 16/09/16 a les 10:58, Xavi Drudis Ferran ha escrit: >> El Fri, Sep 16, 2016 at 09:28:34AM +0200, Narcis Garcia deia: >>> Certament, a /etc/apparmor.d/usr.sbin.cupsd hi ha una línia concernent: >>> /etc/cups/interfaces/* ixrw, >>> L'he desactivat (#) i he hagut d'executar per a què tingui efecte: >>> apparmor stop >>> apparmor teardown >>> apparmor start >>> i ara ja no tinc problema de permisos; tot funciona com s'espera. >>> >>> Gràcies Xavi, Alex, Orestes, Ernest per ajudar-me a encertar en aquest afer. >>> >> >> Però has reiniciat cupsd també ? >> >> Segur que funcionarà quan la màquina reinicii? >> http://wiki.apparmor.net/index.php/FAQ#Controlling_AppArmor >> >> Ës que no en tinc ni idea, però em fa por que el teardown hagi eliminat totes >> les restriccions d'apparmor i el start hagi carregat els perfils per tal que >> _la propera vegada que cupsd s'engigegui_ quedi confinat. Però fins que no >> s'engegui igual està sense cap restricció, no amb el perfil que li has >> modificat. >> >> Vull dir que no sé si ho has arreglat tocat el fitxer de perfil o el que has >> fet ha sigut desactivar apparmor i el cupds en marxa està funcionant sense >> cap perfil per ara... de manera que no sabem si el canvi de perfil funciona >> o no. >> >> Però no en tinc cap pràctica, no em creguis gaire. >> >> > > Gràcies per l'avís; he reiniciat l'ordinador i, com que la norma de > /etc/cups/interfaces/* està deshabilitada, no hi ha norma i no hi ha > permís de res. > Suposo que el "teardown" símplement havia deshabilitat tota norma, i jo > tant feliç. L'estrany és que els "restart" o "reload" que havia provat > no tornés a carregar les normes d'Apparmor. > > Això és una bogeria (també per la sintaxi dels perfils Apparmor), quasi > estic pensant en deshabilitar el perfil complet d'Apparmor per cupsd. > Provaré abans si aconsegueixo afegir permisos pel «sudoers» a > /etc/apparmor.d/local/usr.sbin.cupsd > Ara si: He afegit aquesta línia a /etc/apparmor.d/local/usr.sbin.cupsd : /etc/cups/interfaces/* ux, He reiniciat l'ordinador, i ara el controlador~script de /etc/cups/interfaces/ pot fer el què li doni la gana. Ni tan sols em cal utilitzar el «sudo» per actuar com a un altre usuari.
Re: (deb-cat) sudo as lp
El 16/09/16 a les 10:58, Xavi Drudis Ferran ha escrit: > El Fri, Sep 16, 2016 at 09:28:34AM +0200, Narcis Garcia deia: >> Certament, a /etc/apparmor.d/usr.sbin.cupsd hi ha una línia concernent: >> /etc/cups/interfaces/* ixrw, >> L'he desactivat (#) i he hagut d'executar per a què tingui efecte: >> apparmor stop >> apparmor teardown >> apparmor start >> i ara ja no tinc problema de permisos; tot funciona com s'espera. >> >> Gràcies Xavi, Alex, Orestes, Ernest per ajudar-me a encertar en aquest afer. >> > > Però has reiniciat cupsd també ? > > Segur que funcionarà quan la màquina reinicii? > http://wiki.apparmor.net/index.php/FAQ#Controlling_AppArmor > > Ës que no en tinc ni idea, però em fa por que el teardown hagi eliminat totes > les restriccions d'apparmor i el start hagi carregat els perfils per tal que > _la propera vegada que cupsd s'engigegui_ quedi confinat. Però fins que no > s'engegui igual està sense cap restricció, no amb el perfil que li has > modificat. > > Vull dir que no sé si ho has arreglat tocat el fitxer de perfil o el que has > fet ha sigut desactivar apparmor i el cupds en marxa està funcionant sense > cap perfil per ara... de manera que no sabem si el canvi de perfil funciona o > no. > > Però no en tinc cap pràctica, no em creguis gaire. > > Gràcies per l'avís; he reiniciat l'ordinador i, com que la norma de /etc/cups/interfaces/* està deshabilitada, no hi ha norma i no hi ha permís de res. Suposo que el "teardown" símplement havia deshabilitat tota norma, i jo tant feliç. L'estrany és que els "restart" o "reload" que havia provat no tornés a carregar les normes d'Apparmor. Això és una bogeria (també per la sintaxi dels perfils Apparmor), quasi estic pensant en deshabilitar el perfil complet d'Apparmor per cupsd. Provaré abans si aconsegueixo afegir permisos pel «sudoers» a /etc/apparmor.d/local/usr.sbin.cupsd
Re: (deb-cat) sudo as lp (resolt)
El Fri, Sep 16, 2016 at 09:28:34AM +0200, Narcis Garcia deia: > Certament, a /etc/apparmor.d/usr.sbin.cupsd hi ha una línia concernent: > /etc/cups/interfaces/* ixrw, > L'he desactivat (#) i he hagut d'executar per a què tingui efecte: > apparmor stop > apparmor teardown > apparmor start > i ara ja no tinc problema de permisos; tot funciona com s'espera. > > Gràcies Xavi, Alex, Orestes, Ernest per ajudar-me a encertar en aquest afer. > Però has reiniciat cupsd també ? Segur que funcionarà quan la màquina reinicii? http://wiki.apparmor.net/index.php/FAQ#Controlling_AppArmor Ës que no en tinc ni idea, però em fa por que el teardown hagi eliminat totes les restriccions d'apparmor i el start hagi carregat els perfils per tal que _la propera vegada que cupsd s'engigegui_ quedi confinat. Però fins que no s'engegui igual està sense cap restricció, no amb el perfil que li has modificat. Vull dir que no sé si ho has arreglat tocat el fitxer de perfil o el que has fet ha sigut desactivar apparmor i el cupds en marxa està funcionant sense cap perfil per ara... de manera que no sabem si el canvi de perfil funciona o no. Però no en tinc cap pràctica, no em creguis gaire.
Re: (deb-cat) sudo as lp
El Fri, Sep 16, 2016 at 10:16:56AM +0200, Xavi Drudis Ferran deia: > > > No conec gaire apparmour, però no sé si aquestos s'aplicarien a l'script > de /etc/cups/interfaces. > Ah, doncs res, ja veig que sí. No havia llegit la resposta mentre escrivia...
Re: (deb-cat) sudo as lp
El Fri, Sep 16, 2016 at 12:27:55AM +0200, Alex Muntada deia: > Narcis Garcia: > > > Ja he avançat en el problema (que no en la solució): CUPS executa el > > controlador /etc/cups/interfaces/Epson1 engabiat d'alguna manera, de > > manera que només té accés a alguns directoris. > > > > Això és el què obtinc si el programet només executa "ls /": > > ls: no s’ha pogut obrir el directori /: S’ha denegat el permís > > > > I això per fi he aconseguit si executa sudo -n -u UnUsuari /bin/bash -c > > "ls /" > > sudo: no s'ha pogut obrir /etc/sudoers: S’ha denegat el permís > > sudo: no valid sudoers sources found, quitting > > sudo: unable to initialize policy plugin > > Fa pudor d'apparmor: > > $ apt-file search /etc/apparmor.d/ | grep cups > apparmor: /etc/apparmor.d/abstractions/cups-client > cups-browsed: /etc/apparmor.d/usr.sbin.cups-browsed > cups-daemon: /etc/apparmor.d/usr.sbin.cupsd > > Mira quines restriccions té /etc/apparmor.d/usr.sbin.cupsd perquè > m'ensumo que la cosa va per aquí. > > Salut, > Alex > No conec gaire apparmour, però no sé si aquestos s'aplicarien a l'script de /etc/cups/interfaces. Cupsd no executara l'script d'interfície directament (crec, podria segons casos, sembla). El que fa és generar un profile d'apparmor (en un fitxer temporal) i cridar a /usr/lib/cups/daemon/cups-exec amb el profile i l'script perquè el cridi ell. cups-exec crea un sandbox amb el profile i llavors fa l'exec de l'script El fitxer temporal amb el profile sembla que permet llegir els fitxers de la tasca d'impressió actual (i escriure alguns altres i fer algunes connexions, segons la configuració concreta dels directoris que usa cupsd). No he investigat en detall però possiblement els fitxers de claus públiques de servidors no es poden llegir i ssh (si l'arribes a poder executar) ho té fotut. S'hauria de mirar amb lupa. start_job() crea un profile d'apparmor en un fitxer temporal (a a partir de text hardcoded al programa). https://github.com/apple/cups/blob/master/scheduler/job.c#L4711 https://github.com/apple/cups/blob/master/scheduler/process.c#L72 Després start_job() crida continueJob() https://github.com/apple/cups/blob/master/scheduler/job.c#L482 que crida cupsdStartProcess() https://github.com/apple/cups/blob/master/scheduler/job.c#L1198 https://github.com/apple/cups/blob/master/scheduler/process.c#L450 que decideix si crida cups-exec basat en opcions de compilació i si té profile (sembla que sempre en té, de manera que sempre deu cridar cups_exec) https://github.com/apple/cups/blob/master/scheduler/process.c#L548 cups-exec "si cal" crea un sandbox per executar el procés https://github.com/apple/cups/blob/master/scheduler/cups-exec.c https://github.com/apple/cups/blob/master/scheduler/cups-exec.c#L145 Però cal, perquè li passen el fitxer temporal que han creat abans com a paràmetre profile (no és el primer paràmetre, sinó el primer sense -, el comentari del principi del fitxer és incorrecte, el missatge d'ús del final és correcte). El nom del fitxer temporal no és molt aleatori, es basa en l'hora actual passada a hexadecimal. Segurament hi ha maneres millors de crear fitxers temporals, però potser no tan portables ? El directori serà /tmp, o el valor de $TMPDIR. https://github.com/apple/cups/blob/master/cups/tempfile.c
Re: (deb-cat) sudo as lp (resolt)
El 16/09/16 a les 00:27, Alex Muntada ha escrit: > Narcis Garcia: > >> Ja he avançat en el problema (que no en la solució): CUPS executa el >> controlador /etc/cups/interfaces/Epson1 engabiat d'alguna manera, de >> manera que només té accés a alguns directoris. >> >> Això és el què obtinc si el programet només executa "ls /": >> ls: no s’ha pogut obrir el directori /: S’ha denegat el permís >> >> I això per fi he aconseguit si executa sudo -n -u UnUsuari /bin/bash -c >> "ls /" >> sudo: no s'ha pogut obrir /etc/sudoers: S’ha denegat el permís >> sudo: no valid sudoers sources found, quitting >> sudo: unable to initialize policy plugin > > Fa pudor d'apparmor: > > $ apt-file search /etc/apparmor.d/ | grep cups > apparmor: /etc/apparmor.d/abstractions/cups-client > cups-browsed: /etc/apparmor.d/usr.sbin.cups-browsed > cups-daemon: /etc/apparmor.d/usr.sbin.cupsd > > Mira quines restriccions té /etc/apparmor.d/usr.sbin.cupsd perquè > m'ensumo que la cosa va per aquí. > > Salut, > Alex > Certament, a /etc/apparmor.d/usr.sbin.cupsd hi ha una línia concernent: /etc/cups/interfaces/* ixrw, L'he desactivat (#) i he hagut d'executar per a què tingui efecte: apparmor stop apparmor teardown apparmor start i ara ja no tinc problema de permisos; tot funciona com s'espera. Gràcies Xavi, Alex, Orestes, Ernest per ajudar-me a encertar en aquest afer.
Re: Dubtes sobre instal·lació de paquets específics de Sid.
Hola, El que proposa l'Àlex és el millor. Normalment, si no tens la mala sort de que el paquet que vols instal·lar està immers en una transició (https://release.debian.org/tra nsitions/), els paquets de sid s'instal·len en testing sense problema. El dj 15 de 09 de 2016 a les 15:54 +0200, en/na Alex Muntada va escriure: > Com que testing i unstable no s'allunyen excessivament, per què > no proves d'instal·lar el .deb de unstable directament? Sense > l'apt, vull dir. Com a molt et tocarà instal·lar manualment > alguna dependència i prou. En lloc de fer-ho manualment, es pot fer amb apt: cat > /etc/apt/apt.conf.d/default-release.conf << EOF APT::Default-Release "stretch"; EOF cat > /etc/apt/sources.list.d/sid.list << EOF deb http://httpredir.debian.org/debian sid main contrib non-free EOF apt update apt install -t sid virtualbox virtualbox-qt virtualbox-dkms Amb això hauries de poder instal·lar el virtualbox de sid i potser alguna dependència extra en el pitjor dels casos, sense fer-ho a mà. (disclaimer: no ho he provat, però hui m'he alçat optimista :D) Una vegada el vbox entre en testing, ja no tindràs res amb la versió de sid, i tot normal. Aquesta configuració és útil perquè et permet instal·lar coses de sid, si cal, de manera fàcil, sense perill de que actualitzes a sid del tot. Salut, Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/
