GNU Screen 4.99 - resume non funzionante

[joe]

Già da tempo avevo installato la versione di sviluppo (4.99) di GNU Screen, a me serviva per abilitare i colori truecolor che non sono supportati nella versione stabile del programma.

Il problema che rilevo è l'impossibilità di effettuare il resume di una sessione precedentemente posta in detach. Al resume chiede la password, nessuna è accettata, neanche vuota e in più si inchioda completamente. Alla fine devo chiudere l'intero terminale ST ma anche con XTerm capita, e dare un bruto "pkill -9 screen".

Vi posto i dettagli della clonazione del repo e i passaggi per compilarlo con le opzioni che ho usato, si dovrebbe riuscire a testarlo anche senza installarlo propriamente, dopo il make si trova l'eseguibile nella dir dei sorgenti lavorati:

Codice: Seleziona tutto

git clone git://git.savannah.gnu.org/screen.git

Codice: Seleziona tutto

cd screen/src
autoreconf -vif || exit 101
./configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --libdir=/usr/lib64 \
  --mandir=/usr/man \
  --infodir=/usr/info \
  --with-pty-mode=0620 \
  --with-pty-group=5 \
  --enable-pam \
  --enable-telnet \
  --disable-socket-dir \
  --build=x86-slackware-linux
make

OK, se lo provate su slackware-15.0 autoconf va aggiornato alla versione 2.71 altrimenti dà errore nella generazione del configure (autoreconf).

Una volta ottenuto l'eseguibile "screen", si può testare lanciandolo direttamente dalla dir dei sorgenti "screen/src":

Codice: Seleziona tutto

./screen

A quel punto si esegue il detach premendo "Ctrl+A d" ("Contrl-a" e poi "d"). Questo invia la sessione in background. E si ritorna al prompt precedente.
Infine si può tentare il resume, sempre da lì, dalla dir dei sorgenti, lanciando:

Codice: Seleziona tutto

./screen -r

Dovrebbe chiedere una password. E qui dipende da come è settato PAM se ho ben capito.
Se non avete toccato nulla, non vi dovrebbe più far agganciare la sessione screen.

Invece si può settare PAM come segue in modo da accettare qualsiasi password (ovviamente in certi ambiti la cosa è non sicura, se avete protetto la sessione in ambienti multiuser è ovvio, mentre in ambiti single user non dovrebbe esserci problema e inserire ogni volta la password è una scomodità non accettabile). Ad ogni modo PAM si può settare come segue:

Codice: Seleziona tutto

$ cat /etc/pam.d/screen
#%PAM-1.0

auth            sufficient      pam_permit.so

In teoria così dovrebbe funzionare, cioè al resume chiede la password, si dà invio e si entra.

Nella pratica la cosa me funziona solo se avvio come root screen, a quel punto se mando in detach e poi faccio il resume, chiede la password, do invio ed entro nella sessione senza problemi.

Non capisco perché non funzioni in modo analogo avviando screen da utente semplice...

Sulla mailing devel di screen il problema sembra conosciuto, ma nel mio caso pare che la soluzione che consigliano, ovvero settare pam in modo da accettare qualsiasi password, tamponi la situazione se utilizzo l'utente root, lascio un riferimento:

https://lists.gnu.org/archive/html/scre ... 00024.html

Resta il fatto che tale soluzione non sembra risolvere quando la sessione screen è lanciata da semplice utente, che è poi quello che interessa a me.

Se qualcuno sa che potrebbe centrare PAM e ha idee di cosa potrei provare per risolvere, benvenga, grazie in anticipo!

[rik70]

Qui funziona perfettamente.
Cosa hai in /etc/pam.d/login ?

[joe]

Non ho mai toccato quel file... ecco qua:

Codice: Seleziona tutto

$ cat /etc/pam.d/login
#%PAM-1.0
auth            required        pam_securetty.so
# When using pam_faillock, print a message to the user if the account is
# locked. This lets the user know what is going on, but it also potentially
# gives additional information to attackers:
#auth            requisite       pam_faillock.so preauth
auth            include         system-auth
# To set a limit on failed authentications, the pam_faillock module
# can be enabled. See pam_faillock(8) for more information.
#auth            [default=die]   pam_faillock.so authfail
#auth            sufficient      pam_faillock.so authsucc
auth            include         postlogin
account         required        pam_nologin.so
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         include         postlogin
session         required        pam_loginuid.so
-session        optional        pam_ck_connector.so nox11
-session        optional        pam_elogind.so

Pensavo... da te con quale terminale hai provato?
Non si sa mai che c'entri qualcosa anche quello.. anzi spetta che provo, perché di solito uso ST (suckless.org). E con questo rilevo il problema. Vedo di fare qualche prova anche con "xterm".

[rik70]

Terminale Konsole.
Ma anche da ssh.
Il pacchetto ufficiale screen aggiunge /etc/pam.d/screen con questo contenuto

Codice: Seleziona tutto

#%PAM-1.0

auth            required        pam_securetty.so debug
auth            include         system-auth

ma sembra del tutto ininfluente: anche rimuovendo, o "commentando" quel file, funziona.

[joe]

Allora sì, per qualche santo con xterm sembra funzionare anche come utente semplice.

Ricapitolando:

1. con ST
- come root funziona il resume
- come user NON funziona

2. con Xterm
- come root non ho neanche provato
- come utente semplice FUNZIONA

Non so, se per caso hai ST installato e vuoi fare una prova... ad ogni modo grazie per il feedback, adesso l'inghippo sembra un po' più circoscritto.
Per ottenere una configurazione comprensiva di varie funzionalità relative allo stile dei font nel terminale, tipo l'italic ecc ecc, avevo ritoccato il "terminfo" di "st". Potrebbe anche essere un effetto collaterale a quelle impostazioni...

[joe]

Aggiungo una cosa su PAM.
Se utilizzo la configurazione originaria che hai postato tu, usando XTerm (quindi un terminale che non presenta il problema del crash) mi chiede la password al resume, io do invio e però lui mi ritorna "Password incorrect".
Invece modificando "pam.d/screen" come ho mostrato nel mio primo messaggio, ecco che dando invio alla richiesta della password entro senza problemi.

Per capirci, a me non interessa settare una password, voglio solo poter inviare la sessione screen in detach e farne il resume in seguito. A volte capita anche di premere accidentalmente "ctrl-a d" e buttare tutto in background... se dopo non si riesce a ripescare la sessione può essere anche un problema se conteneva roba non salvata ad esempio.

[rik70]

Io qui non riesco a riprodurre quanto dici.

Su una sessione KDE/plasma, lancio Xterm poi screen. Al resume mi chiede la password, digito e funziona.

Non ho il pacchetto screen installato e il suo file /etc/pam.d/screen è stato rimosso.

Hai provato su un'altra sessione grafica?

P.s.

Stessa cosa da init 3 su una sessione grafica tipo:

Codice: Seleziona tutto

xinit /usr/bin/xterm -- vt01

[joe]

Spetta, ma cosa digiti, cioè quale password inserisci?
Quella dell'utente semplice che stai usando?

Io sono in init5, però con "dwm" (sempre suckless.org come il terminale ST).

PS.
Ad ogni modo pare che abbia risolto il problema principale del crash, era effettivamente relativo al file "terminfo" di ST. Ne usavo uno specifico per l'utente, mentre root usava quello di sistema in /usr/share/terminfo. Ho fatto un diff tra i due e a quello dell'utente mancavano alcune cosette. Magari metto il dettaglio in un successivo post per completezza.

[joe]

Prova un po' questa (che casino!):

Con /etc/pam.d/screen di Pat, quello sopra originale che dicevi, ovvero:

Codice: Seleziona tutto

#%PAM-1.0

auth            required        pam_securetty.so debug
auth            include         system-auth

Con questa roba, ho provato e da utente semplice mi funziona tutto (poi spiego la faccenda terminfo che non c'entra con PAM).
Cosa intendo:
- lancio ST
- screen
- ctrl+a d
- screen -r
- Password
- digito la password dell'utente semplice ed entro. Se batto solo invio non entro.

Con PAM editato come nel mio esempio cioè commentando le due righe auth e inserendo quella più insicura:

Codice: Seleziona tutto

auth            sufficient      pam_permit.so

Ecco che così quando chiede la password accetta qualsiasi stringa, anche vuota cioè batti invio e sei dentro.

Ma la cosa singolare è se si fa la stessa cosa da root, ovvero:
- sono in sessione grafica come user
- lancio ST come user
- su - (ora sono root)
- lancio screen (come root quindi)
- ctrl+a d
- screen -r
- Password
- inserisco la password di root (per coerenza con la prova da user semplice) e me la rifiuta
- inserisco la password dello user, e me la rifiuta
- inserisco semplicemente invio, e me lo rifiuta
Insomma non si entra più nella sessione screen!

Questo caso è raro nel senso che solitamente si avvia screen da utente e poi si fa il login come root solo in alcune shell. Però potrebbe anche tornare utile avere l'intera sessione screen con i privilegi di root e aprire enne schermate tutte con i privilegi di super utente... In questo caso con PAM impostato come il default di Slackware quindi in modo stringente (giustamente immagino) non saprei come rientrare in una sessione mandata in detach.

[rik70]

Spetta, ma cosa digiti, cioè quale password inserisci?
Quella dell'utente semplice che stai usando?

Sì.

Da utente root funziona allo stesso modo.

Il tutto a prescindere dall'esistenza o meno del file /etc/pam.d/screen del pacchetto.

[rik70]

Il tutto a prescindere dall'esistenza o meno del file /etc/pam.d/screen del pacchetto.

No, aspetta: con l'opzione pam del pacchetto screen, da 'root' ho lo stesso problema tuo.
Ma se lo rimuovo o lo cambio così

Codice: Seleziona tutto

cat /etc/pam.d/screen 
#%PAM-1.0

#auth		required	pam_securetty.so
#auth		include		system-auth

auth		required	pam_unix.so

funziona anche da root.

[joe]

Ignorantemente ignoro PAM e la sua sintassi... La modifica che avevo fatto l'ho appresa dalla mailing di GNU screen, e direi che lascerò quella vista la comodità.
Però non so quali problematiche di sicurezza implichi. Di fatto consente di fare il resume immettendo qualsiasi password.
Ma in ambiente single user non saprei che problema ci sia.

Certo, se un ipotetico hacker accede al tuo sistema si può agganciare senza nessuna password ad una eventuale sessione screen in cui vi è una schermata con log di root attivo, e di fatto si ritrova loggato come root senza neanche bisogno di password ecc... Però se uno ti entrato nel sistema probabilmente certi privilegi di super utente li ha già in mano... ma non so, parlo ignorantemente.

[rik70]

Ma in ambiente single user non saprei che problema ci sia.

Nemmeno io.
Però dai un occhiata a 'man pam_securetty' e '/etc/securetty'.

Praticamente l'errrore da root è dovuto a quella regola pam di screen che invoca restrizioni su quali terminali può autenticarsi l'utente root.
Quindi, mantenendo ferma la regola del pacchetto screen

Codice: Seleziona tutto

#%PAM-1.0

auth            required        pam_securetty.so
auth            include         system-auth

devi 'decommentare' 'pts/*' in /etc/securetty per consentire all'utente root di autenticarsi quando fa il resume con screen 'fuori' dalle tty.
Teoricamente questo però dovrebbe aprire problemi di sicurezza.

Ora, non so perché PAT ha messo quella regola (solo(?)) per screen, ma una ragione penso ci sarà.

Altre distribuzioni non la usano, impostando la sola 'pam_unix' vista sopra.

[joe]

Per il mio scopo l'ottimo sarebbe eliminare completamente la richiesta di password per l'utente semplice (con la possibilità di attivarla alla bisogna) e lasciarla per l'utente root. Come dicevo che io ricordi non mi è mai servito avviare un'intera sessione screen da root, nell'eventualità sarebbe comunque preferibile mantenere una certa barriera di sicurezza predisponendo una password in caso di detach, però che funzioni, come hai mostrato con "pam-unix".

In pratica una cosa del tipo:
- pam-unix per sessioni avviate da root
- pam_permit.so per l'utente semplice di nostra scelta

Eventualmente cerco... ma come dicevo non ne so proprio niente di PAM, per cui non prometto nulla.

Risolti questi aspetti correlati al detach e resume di screen, provo anche a crearne un pacchetto da slackbuild. In precedenza usavo la versione 4.99 (come accennato per via del supporto a truecolor mentre con screen 4.x stabile vi si deve rinunciare) pacchettizzata con lo slackbuild di Pat, mi pare avessi tolto via qualche patch che non si riusciva ad applicare, ma va be' alla fine nell'utilizzo non mi sono accorto di problemi particolari se non di roba relativa a "terminfo" (tipo supporto all'italic e altre feature dei fonts) che avevo cercato di tamponare (piantandoci anche qualche errore come è si è capito adesso) e l'unico problema che avevo notato era il resume impossibilitato sotto il terminale "st".

Va bene, per il momento grazie delle risposte!

[rik70]

provo anche a crearne un pacchetto da slackbuild. In precedenza usavo la versione 4.99

Dallo SlackBuild ufficiale:

Codice: Seleziona tutto

# Sorry, pal.  Not around here.
chmod 755 $PKG/usr/bin/screen-$VERSION

Ma poi:

Codice: Seleziona tutto

# Choose correct options depending on whether PAM is installed:
if [ -L /lib${LIBDIRSUFFIX}/libpam.so.? ]; then
  PAM_OPTIONS="--enable-pam"
  unset SHADOW_OPTIONS
else
  unset PAM_OPTIONS
  SHADOW_OPTIONS="--disable-pam"
fi

Codice: Seleziona tutto

if [ ! -z "$PAM_OPTIONS" ]; then
  mkdir -p $PKG/etc/pam.d
  cat $CWD/screen.pam > $PKG/etc/pam.d/screen.new
fi

Codice: Seleziona tutto

  
[...]
./configure  \
  [...]
  $PAM_OPTIONS \
  $SHADOW_OPTIONS \
  [...]

Parla da solo

Pam nella 15.0 c'è, quindi compila con '--enable-pam'.
Però non vuole pam(refuso del passato?) in mezzo alle balls e toglie il setuid dall'eseguibile screen, ma poi installa la regola pam per screen.

Il setuid in realtà servirebbe, in unione col supporto socket-dir - che lui disabilita - per mettere i socket di screen fuori dall'home dell'utente, piazzandoli in una sottocartella di /run/screen accessibile solo dall'utente dell'istanza screen.


Ok, mi fermo
ma trovi riscontri nella documentazione dei sorgenti.

Probabilmente l'approccio cambierà con le future versioni stabili di screen.