google-chrome e /dev/shm

[conraid]

Dopo che Pat ha messo il build per chrome ho creato ed installato il pacchetto. L'ho provato solamente quel giorno, funzionava correttamente e poi non ho più avviato chrome.
Premetto che ho creato "chrome" e non "chromium", quindi non ho installato libpam
Stamani vado ad avviare chrome e...

Codice: Seleziona tutto

[4650:4660:7638332395:ERROR:shared_memory_posix.cc(153)] Creating shared memory in /dev/shm/.com.google.chrome.KTyxUq failed: Permesso negato
[4650:4660:7638332490:ERROR:shared_memory_posix.cc(156)] Unable to access(W_OK|X_OK) /dev/shm: Permesso negato
[4650:4660:7638332513:FATAL:shared_memory_posix.cc(158)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.

Ho provato a cambiare le impostazioni di fstab per /dev/shm come consigliato in rete, mettendo

Codice: Seleziona tutto

tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)

ma niente. Alla fine ho fatto quel che ha consigliato l'output di chrome, naturalmente senza sudare
Così che da 755 siamo passati a 777 con proprietario root:root
Ma non mi sembra una cosa molto saggia, e se l'unico programma a non funzionare con questo è chrome...

Quel che mi domando è:
- cosa è cambiato da quel giorno ad oggi? qualche nuovo pacchetto ha cambiato le impostazioni di defaults (i parametri con cui montavo /dev/shm erano proprio "defuaults") di tmpfs o cosa?
- è qualche parametro del kernel? tipo CONFIG_TMPFS_POSIX_ACL=y che comunque non ho modificato da qualche kernel a questa parte ed è anche nel generic di Pat, e quindi mi domando il perché del comportamento diverso. Tra l'altro dalla man page di "mount" le acl posix non sono impostabile in tmpfs, o ho capito male?
Come kernel utilizzo il 2.6.38.2 con un config mio, ma non modificato da tempo, se non per qualche impostazione ipv6 (non ho ancora provato a lanciare il vecchio kernel o il generic)
- cosa comporta mettere 777 a /dev/shm?

[hashbang]

Quel che mi domando è:
- cosa è cambiato da quel giorno ad oggi? qualche nuovo pacchetto ha cambiato le impostazioni di defaults (i parametri con cui montavo /dev/shm erano proprio "defuaults") di tmpfs o cosa?

A me è capitato lo stesso problema con Chromium (compilato nativamente). Il problema però è che questo problema una volta mi è successa a distanza di un reboot, quindi non penso che sia stato qualche nuovo pacchetto.

- è qualche parametro del kernel? tipo CONFIG_TMPFS_POSIX_ACL=y che comunque non ho modificato da qualche kernel a questa parte ed è anche nel generic di Pat, e quindi mi domando il perché del comportamento diverso. Tra l'altro dalla man page di "mount" le acl posix non sono impostabile in tmpfs, o ho capito male?

All'inizio ho pensato a qualche problema con udev, ma non ne sono sicuro. Anche perchè una volta mi è accaduto dopo un reboot. Tra l'altro anche su questo forum chiedono di udev.

- cosa comporta mettere 777 a /dev/shm?

Guarda sinceramente io l'ho fatto e non ho avuto problemi. Comunque questa soluzione la temo un pò. Sinceramente non mi va di dare i permessi totali alla shared memory, specie quando il problema è causato da un conflitto con il browser web. Poi magari sarò paranoico io...

[414N]

Io sulla 13.1 ho /dev/shm montato di default con permessi 777. In fstab l'unica opzione che c'è è defaults.

[conraid]

Non ho ancora fatto il reboot, ma in rc.udev c'è una regola che prima fa umount /dev/shm e poi mount mode=755 quindi immagino che udev ad ogni avvio cambi le impostazioni, ma non vedo nel build o in doinst.sh qualche regola che imposti a 777, e quindi anche la prima volta i permessi di shm erano 755
boh...


update:
modificandoli al riavvio rimangono come sono stati impostati

[conraid]

nel notebook, con slackware64 i permessi di /dev/shm sono 777, al che ho pensato "sarà qualche pacchetto diverso".
/dev/shm è creato dal pacchetto devfs ed in entrambe le versioni crea un device con permessi 755 (provato anche in chroot, anche con la 13.1), quindi è qualcosa successivamente che ha modificato tali permessi
non indago oltre per adesso

[conraid]

tanto per gradire e tornare sull'argomento, stamani avvio chrome e... stesso problema con i permessi di /dev/shm
non ricordo però se in questi giorno dopo l'upgrade della -current l'ho avviato, anche se mi sembra di sì, però dove sarà l'inghippo?

[hashbang]

A quanto mi sembra di leggere in giro, il problema è un bug di Chromium/Chrome che porta il browser a fare a cazzotti con i permessi di /dev/shm.

C'è chi come soluzione propone di cambiare il parametro 'ro' in 'rw' in /etc/fstab e c'è chi propone altre modifiche (sempre a fstab).

Ora, non so se queste soluzioni siano attualmente funzionanti. Le testerei volentieri, ma sono impossibilitato.