L'helper di Squid vede il modulo. Ma riesce a leggerlo?

Prima di aggiungere l'account Squid a un altro gruppo, controllate cache_effective_group. In Squid 5–7 l'impostazione predefinita usa i gruppi primari e supplementari dell'utente effettivo. Una sostituzione esplicita fa sì che Squid ignori i privilegi degli altri gruppi, quindi l'appartenenza appena aggiunta potrebbe non raggiungere mai il suo helper.

È uno dei modi in cui un modulo Perl può esistere sul disco e comunque non caricarsi. Distinguete tre cause nell'errore reale del caricatore: la dipendenza è assente, è fuori dal percorso di ricerca dell'interprete, oppure il servizio non può leggerla.

Confrontate il modulo e ogni directory superiore sotto l'identità di esecuzione dell'helper. L'interprete ha bisogno di attraversare le directory e leggere i file, non solo di un nome file finale leggibile. Dopo un aggiornamento, la proprietà del fornitore o le modalità predefinite possono differire dalla disposizione che funzionava prima.

Scegliete una concessione di permessi ristretta, coerente con l'account di servizio previsto e con l'impostazione del gruppo effettivo. Leggere una dipendenza non richiede di rendere scrivibile l'intero albero dell'applicazione da parte del proxy. Ricreate i processi interessati tramite il ciclo di vita supportato del servizio dopo le modifiche ai gruppi; quelli esistenti possono conservare le vecchie appartenenze.

Se i percorsi di ricerca e i permessi ordinari concordano, esaminate la vista del servizio sul filesystem e le prove del controllo di accesso obbligatorio. Il fatto che una shell root carichi il modulo con successo non dimostra nessuna di queste condizioni per l'helper.