CUPS 1.4.6 filter permission - Megoldva

 ( diego | 2017. március 1., szerda - 22:32 )

Sziasztok. Pénteken este, és a hétvégén a Cups-pdf beállításaival bajlódtam, de a végén sikerült az egészet valahogy elqúrni. Ezt nem is vettem észre, csak hétfő reggel, mikor jelezték, hogy nem mennek a nyomtatók. A jelenség röviden a következő: A nyomtatás létrejön, a /var/spool/cupsban létrejön a leíró file és a nyomtatandó tartalom, de a filterek már nem férnek hozzá ezekhez, "Unable to open file "/var/spool/cups/d1234567-001": Permission denied". Ha manuálisan átírom a jogosultságot, és újraindítom a nyomtatót, akkor kinyomtatódik, de a következő már megint bentragad. Ez a jogosultság hiba az összes filternél előjön. A nyomtatásnál root:lp -rw-r----- a nyomtatandó tartalom, ezt nem tudják olvasni a filterek. (amiknek elvileg lp userként kéne menniük) Ami még érdekes, hogy a próbanyomtatás képe megváltozott, az eredeti, "csecsás" cups mintaoldal helyett csak egy egyszerű oldalt nyomtat, és más a grafika.

A rendszer: Linux 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux openSUSE 11.4 (x86_64) CODENAME = Celadon CUPS=1.4.6., root:lp
A rendszer tartalmazza az elérhető frissítéseket, de dist upgrade nem lehet szerveren futó linuxos ERP rendszer miatt, ami egyedi fejlesztés(volt) és itt megállt. Előtte tökéletesen működött, most valami nagyon el lett cseszve.

Eddig az alábbiakat néztem át: debug bekapcsolva, logban a hibán kívül semmi támpont. Apparmor cups profil letiltva, apparmor eltávolítva. cups config default (sys root), a könyvtárak és a file-ok mérete, jogosultsága (/etc/cups, usr/lib/cups, usr/share/cups) megegyeznek a telepítőcsomag eredeti állományaival. Próbáltam azt is, hogy a /var/cache/cups alól kitöröltem amit lehetett, semmi. Próbáltam azt is, hogy egy-egy nyomtatót töröltem, majd újratelepítettem. Semmi. Egy másik szerveren levő ugyanilyen CUPS jogosultságai, beállításai alapján átnéztem mindent. Semmi. Így három nap után kezdem feladni, már minden szóba jöhető ötletet végignéztem.
Jelenleg egy végtelenített script fut, ami kb 30 másodpercenként átírja a jogosultságot, és újraindítja a nyomtatást, így működőképes maradt a rendszer, de ez csak gányolás.
Ami nem jöhet szóba: Dist upgrade, Cups újratelepítés (kb 50 nyomtató van szanaszét a megyében, ami 05-22 idő alatt full-ba nyomja, utána meg indulnak a mentési és egyéb hosszabb scriptek)
Valakinek valami ötlete, tippje??? Előre is köszönöm!

Utóirat, hátha így érthetőbb:

$id lp -> uid=4(lp) gid=7(lp) csoportok=7(lp)
Ezeket a dir jogosultságokat a cups állítja be, mikor újrainditódik, hiába módosítod bármi másra, a beállítás az első cups restartig él.
/var/spool                         │drwxr-xr-x│root│root│
/var/spool/cups                    │drwx--x---│root│lp  │
/var/spool/cups/c1429149     │  815│-rw-------│root│lp  │
/var/spool/cups/d1429149-001 │ 5759│-rw-r-----│root│lp  │

Az auditlogban az látszik, hogy az lp jogosultsággal futó socket (de mindegyik filternél ugyan ez a helyzet) nem tudja olvasni a nyomtatást

type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 id=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"

/var/log/audit # ausearch -a 2162
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.419:2162): cwd="/"
type=SYSCALL msg=audit(1488573307.419:2162): arch=c000003e syscall=82 success=yes exit=0 a0=7f22f4936e64 a1=7fff4c69d670 a2=7fff4c69d68c a3=63205d303031302b items=4 ppid=1 pid=18624 auid=1277 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1337 comm="cupsd" exe="/usr/sbin/cupsd" key="cups_spool_dir_access"

/var/log/audit # ausearch -a 2163
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.422:2163): item=0 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.422:2163): cwd="/"
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"


A CUPS webes admin felületén pedig ott virít, hogy: pending since 2017....Unable to open print file "/var/spool/cups/d1429149-001": Permission denied
Ezek után tipp valakitől? Mit nem látok???
Megoldás:
A cups-pdf (valami béta verzió volt) elállította a /var/spool/cups umask értékét, konkrétan kitörölte, üres volt. Ennek beállítása után (getfacl, setfacl) helyreállt minden.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Csak egy ötlet: ha a user-eket felveszed az lp csoportba, tudják majd olvasni a file-okat, hiszen az lp csoportnak van olvasási joga a file-ra.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kipróbáltam, nem ez a gond. Az userek tudnak nyomtatni, a spool file-ok létrejönnek, a command, postscript, és egyéb filterek nem tudják olvasni a spool-t.

Akkor azt nézd meg, azok a process-ek, amelyek nem tudják olvasni, kinek a nevében futnak.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A cups root-ként fut, de a processeket nem tudom monitorozni, mert nem marad futó állapotban, hanem leáll azonnal. (Az előző lp+userekhez még annyit, hogy előtte sem kellett, és a másik gépen is e nélkül megy. de én is kipróbáltam.)

Ugyan Fedora 25-ön nézem, 4.9.13-as kernelem van, 2.2.0-ás cups, de ezt látom az /etc/cups/cups-files.conf file-ban:

# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Itt számit a verzió. Az 1.4.6-nál az LP:LP-re azt mondja újraindítás után, hogy az nem jó, és átállitja lp:nobody-ra, de ne kérdezd, hogy miért. Ez a verzio sys:root configgal megy, ebben biztos vagyok.

Nem ez volt a mondandóm lényege, hanem az, hogy a konfigurációs file-ban megadhatod, ezek a file-ok milyen tulajdonossal és csoporttal jöjjenek létre. Figyelj arra, hogy default ki van kommentelve!

Szerk.: és persze LP:LP != lp:lp


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az én mondandóm meg az volt, hogy ezen a verzión ez nem működik, mert ha a configban ez van:
#SystemGroup sys root
SystemGroup lp lp

akkor ez van a logban:
Loaded configuration file "/etc/cups/cupsd.conf"
Group and SystemGroup cannot use the same groups!
Resetting Group to "nobody"...

és igen, az LP:LP != lp:lp :-)
Update, hogy megnyugodjon a lelkiismeretem:
Configba bekerült: user:lp group:lp, majd próbanyomtatás:
"Unable to open banner file "/var/spool/cups/d1422070-001" - Permission denied", a létrehozott file: root │lp │-rw-r-----│

OK, de nálam nem ez van. Van SystemGroup is, de amit én mondtam, az fölötte van. Hogy jobban lásd:

#
# File/directory/user/group configuration file for the CUPS scheduler.
# See "man cups-files.conf" for a complete description of this file.
#

# List of events that are considered fatal errors for the scheduler...
#FatalErrors config

# Do we call fsync() after writing configuration or status files?
#SyncOnClose Yes

# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
 SystemGroup sys root wheel

# User that is substituted for unauthenticated (remote) root accesses...
#RemoteRoot remroot

# Do we allow file: device URIs other than to /dev/null?
#FileDevice No

# Permissions for configuration and log files...
#ConfigFilePerm 0640
#LogFilePerm 00600

# Location of the file logging all access to the scheduler; may be the name
# "syslog" (syslog means systemd journal by default). If not an absolute path, the value of ServerRoot is used as the
# root directory.  Also see the "AccessLogLevel" directive in cupsd.conf.
AccessLog /var/log/cups/access_log

# Location of cache files used by the scheduler...
#CacheDir /var/cache/cups

# Location of data files used by the scheduler...
#DataDir /usr/share/cups

# Location of the static web content served by the scheduler...
#DocumentRoot /usr/share/cups/www

# Location of the file logging all messages produced by the scheduler and any
# helper programs; may be the name "syslog" (syslog means systemd journal by default). If not an absolute path, the value
# of ServerRoot is used as the root directory.  Also see the "LogLevel"
# directive in cupsd.conf.
ErrorLog syslog

# Location of fonts used by older print filters...
#FontPath /usr/share/cups/fonts

# Location of LPD configuration
#LPDConfigFile 

# Location of the file logging all pages printed by the scheduler and any
# helper programs; may be the name "syslog" (syslog means systemd journal by default). If not an absolute path, the value
# of ServerRoot is used as the root directory.  Also see the "PageLogFormat"
# directive in cupsd.conf.
PageLog /var/log/cups/page_log

# Location of the file listing all of the local printers...
#Printcap /etc/printcap

# Format of the Printcap file...
#PrintcapFormat bsd
#PrintcapFormat plist
#PrintcapFormat solaris

# Location of all spool files...
#RequestRoot /var/spool/cups

# Location of helper programs...
#ServerBin /usr/lib/cups

# SSL/TLS keychain for the scheduler...
#ServerKeychain ssl

# Location of other configuration files...
#ServerRoot /etc/cups

# Location of Samba configuration file...
#SMBConfigFile 

# Location of scheduler state files...
#StateDir /var/run/cups

# Location of scheduler/helper temporary files. This directory is emptied on
# scheduler startup and cannot be one of the standard (public) temporary
# directory locations for security reasons...
#TempDir /var/spool/cups/tmp


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az user/group paraméter nem volt az előző konfigban, és a másik két szerveren is enélkül a paraméter nélkül MŰKÖDIK. Most még egyszer kipróbáltam az összes verziót (root:lp, lp:lp, lp:root) de az eredmény ugyanaz mindegyiknél. Valami más van elállítódva.
Up!

Erre azt tudom mondani, hogy te tudod, mihez nyúltál hozzá, hiszen ez valaha működött. Sőt, ha jól értelek, van olyan géped, ami most is jó, tehát akár file-onként össze tudod hasonlítani őket.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az összehasonlításon már túl vagyok. Fájlonként. Dátumonként. Méretenként. Jogosultságonként. A cups-pdf lett telepítve, majd eltávolítva. Ennek ellenére sem stimmel valami. Igen. Ha tudnám, hogy mi állítódott el, akkor valószínűleg nem ide írtam volna. :-( De ezzel kezdtem az egész topicot... Ezeken már túl vagyok.

Azért gondolom, érzed az ellentmondást. Még felhasználónként is vannak a cups-nak beállításai, bár azt nem hiszem, hogy ilyen globális dolog, mint a jogosultság kezelés így lenne megoldva. Gyakorlatilag kizárt.

Jut eszembe, írtad a cups-pdf-et. Egyrészt jó cucc, én használom, szeretem, működik, amellett van fizikai nyomtatóm, az is működik, szóval nem hinném, hogy önmagában ez lenne a baj. Ugyanakkor gondold csak végig, mi történik.

Telepítéskor felkerülnek a cups-pdf csomag file-jai. Módosítasz a konfigján. Aztán eltávolítod. Minden eltávolításra kerül, kivéve a cups-pdf módosított konfigja, illetve azok a file-ok, amelyek esetleg a post install script által jöttek létre. Ennek is nézz utána, mert ez a konfig hatással lehet a cups szerver működésére.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Process accounting vagy auditd segitene kibogaraszni, mi is tortenik (mi milyen felhasznalokent fut). Utana mar konnyebb lenne rajonnod, mi ment felre. A frissithetetlen rendszer meg vagy containerbe, vagy VM-be valo.

Köszi a tippet, én is átnéztem már, de ha kiküldök egy nyomtatást, ide semmi hibát nem ír, sőt, semmit se ír.
Ilyeneket látok benne:
type=AVC msg=audit(1488523445.665:1153): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 pid=21267 comm="sshd"

Gondolom nincs audit szabalyod a /var/spool/cups konyvtarra, vmi ilyesmit vegyel fel pl:
-w /var/spool/cups/ -p rw -k cups_spool_dir_access
es utana nezd meg ausearch-csel, az minden osszetartozo rekordot kikeres, abbol latszik, tenylegesen milyen felhasznaloval futott a filter.

Köszönöm! Kipróbálom ezt is! Itt az eredmény...

$id lp -> uid=4(lp) gid=7(lp) csoportok=7(lp)
Ezeket a dir jogosultságokat a cups állítja be, mikor újrainditódik, hiába módosítod, a beállítás az első cups restartig él.
/var/spool                         │drwxr-xr-x│root│root│
/var/spool/cups                    │drwx--x---│root│lp  │
/var/spool/cups/c1429149     │  815│-rw-------│root│lp  │
/var/spool/cups/d1429149-001 │ 5759│-rw-r-----│root│lp  │

Az auditlogban az látszik, hogy az lp jogosultsággal futó socket (de mindegyik filternél ugyan ez a helyzet) nem tudja olvasni a nyomtatást

type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 id=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"

/var/log/audit # ausearch -a 2162
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.419:2162): item=3 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=2 name="/var/spool/cups/00000000" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=1 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=PATH msg=audit(1488573307.419:2162): item=0 name="/var/spool/cups/" inode=6029564 dev=08:13 mode=040710 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.419:2162): cwd="/"
type=SYSCALL msg=audit(1488573307.419:2162): arch=c000003e syscall=82 success=yes exit=0 a0=7f22f4936e64 a1=7fff4c69d670 a2=7fff4c69d68c a3=63205d303031302b items=4 ppid=1 pid=18624 auid=1277 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1337 comm="cupsd" exe="/usr/sbin/cupsd" key="cups_spool_dir_access"

/var/log/audit # ausearch -a 2163
time->Fri Mar 3 21:35:07 2017
type=PATH msg=audit(1488573307.422:2163): item=0 name="/var/spool/cups/d1429149-001" inode=6035245 dev=08:13 mode=0100640 ouid=0 ogid=7 rdev=00:00
type=CWD msg=audit(1488573307.422:2163): cwd="/"
type=SYSCALL msg=audit(1488573307.422:2163): arch=c000003e syscall=2 success=no exit=-13 a0=7fff3ccdbcc9 a1=0 a2=0 a3=7fff3ccd8b60 items=1 ppid=18624 pid=18790 auid=1277 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=1337 comm="socket" exe="/usr/lib/cups/backend/socket" key="cups_spool_dir_access"


A CUPS webes admin felületén pedig ott virít, hogy: pending since 2017....Unable to open print file "/var/spool/cups/d1429149-001": Permission denied
Ezek után tipp valakitől? Mit nem látok???

Hmm... A /var/spool alatt minden jo, szoval csak az okozhatna gondot, ha a /var nem lenne jol beallitva, azaz ha nem lenne hozza mindenkinek x joga.

Szerintem az is jó. Ezért nem értem. :-(
/var   │4096│root│root│drwxr-xr-x│

De azt is kipróbáltam, hogy su lp, majd cat /var/spool/cups/d1429149-001 : permission denied. :-(
up.

Na jó, de az már a jogokból látszik, hogy nem fog menni. Neked az lp csoportban kell lenned. Tényleg, nem lehet, hogy csak valami ilyesmi hiányzik?

usermod -a -G lp lp

Persze root-ként kiadva, s feltéve, hogy az lp csoport már létezik.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem. Olvass vissza, és nézd meg az audit kimenetét.

Bocs, tényleg odamásoltad az id lp kimenetét, s az jó.

Szerk.: komolyabb végiggondolás nélkül jártatom a szám... A /var nem önálló filerendszer? Nem lehet, hogy ebben az esetben valamilyen mount opció korlátoz?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez vonatkozik rá, nincs külön var partició
/dev/disk/by-id/scsi-....b6-part3 / ext4 acl,user_xattr 1 1
de ehhez meg aztán végképp nem nyúlt senki... Valami ACL lesz, de nem tudom, hogy mi?

Akkor lsattr meg getfacl.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Megvan, hogy a .....
A spool/cups mask üres volt, így az effektív acl is üres lett. Javítva, és láss csodát :-) :-) :-) Megint jó!!! Legalábbis itthonról nézve úgy tűnik :-)
Köszönöm a segítséget!!!

Szívesen. :) Különben az a vicces, hogy magadat vezetted rá, én csak egy hajszálnyit tettem hozzá azzal a két paranccsal. :) Viszont magam is tapasztaltam, hogy az együtt gondolkodás motiválttá teszi az embert, s olykor képessé arra, hogy kívülről, más aspektusból lássuk a problémát.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE