Sulla base della risposta di Toby, ho trovato un modo per configurarlo in modo leggermente diverso su Debian / Ubuntu. Per il contesto, vedere:
Quindi Debian / Ubuntu ha questo pam-auth-updatecomando e quando lo guardi /etc/pam.d/sudoappare così:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
e si /etc/pam.d/common-session-noninteractivepresenta così:
#
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of all non-interactive sessions.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config
Quindi certo, potrei modificare uno dei file sopra ma chiaramente c'è qualcosa di "più potente" al lavoro qui. Come far funzionare bene le mie modifiche con altri pacchetti che potrebbero voler aggiungere regole pam? Per finire, sembrava che non potessi semplicemente aggiungere una linea /etc/pam.d/sudotra le due @includes in questo modo ..
##### THIS DIDN'T WORK :( ######
@include common-auth
@include common-account
session [default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser
@include common-session-noninteractive
Dopo aver letto i link sopra e altri esempi (vedi /usr/share/pam-configs/unix), ho trovato questo, in /usr/share/pam-configs/myapp:
# Don't log "session opened" messages for myapp user
# See: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
# https://manpages.debian.org/stretch/libpam-modules/pam_succeed_if.8.en.html
Name: myapp disable session logging
Default: yes
Priority: 300
Session-Type: Additional
Session:
[default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser
Sessione Session-Typecontrolla quali file vengono modificati e Prioritydefinisce in quale ordine vanno. Dopo aver aggiunto quel file ed eseguito pam-auth-update, /etc/pam.d/common-session-noninteractiveappare così (in fondo :)
#... omitted
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session [default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser
session required pam_unix.so
# end of pam-auth-update config
... che è quello che vogliamo perché la nostra pam_succeed_iflinea deve venire prima session required pam_unix.so. (Quella linea viene da /use/share/pam-configs/unixe ha un Priority: 256quindi finisce secondo.) Nota anche che ho lasciato il service = sudopredicato poiché common-session-noninteractivepotrebbe anche essere incluso in altre configurazioni oltre sudo.
Nel mio caso, avevo già impacchettato il mio codice come programma di installazione .deb, quindi ho aggiunto il /usr/share/pam-configs/myappfile, aggiunto pam-auth-update --packageal mio postinste agli prermscript e sono a posto!
Avvertimento...
Se leggi l' articolo PAMConfigFrameworkSpec che ho collegato sopra , definisce Session-Interactive-Onlyun'opzione, ma non ha un modo per specificare solo regole non interattive . Quindi è /etc/pam.d/common-sessionstato anche aggiornato . Non penso che ci sia un modo per aggirare questo. Se sei d'accordo con le sessioni interattive non registrate per quell'utente (è un account di servizio, giusto?) Allora dovresti essere pronto!
Bonus: come rimuovere anche l'output del registro sudo
Oltre alle session openened|closedrighe emesse da PAM, sudoregistra ulteriori informazioni sul comando eseguito. Sembra così:
[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...
Se vuoi anche rimuoverlo, apri questo link quindi continua sotto ...
Quindi ... probabilmente hai familiarità con la /etc/sudoers.d/___configurazione tipica che potrebbe fare qualcosa del genere per un account di servizio che necessita di privilegi di superutente per alcune azioni:
myuser ALL=(ALL) NOPASSWD: /bin/ping
che potrebbe entrare /etc/sudoers.d/10_myuser. Bene, tra l'altro puoi anche specificareDefaults . Nota in particolare questa sintassi'Defaults' ':' User_List
Ora, guarda la sezione OPZIONI SUDOERS . Bit interessanti includono log_input, log_outputma (probabilmente) ancora più importante, sysloge logfile. Mi sembra che nelle ultime versioni di Debian, sia rsyslog o sudoaccedi stdouto stderrdi default. Quindi per me questo è stato mostrato nel registro dei giornali per il mio servizio, e non ad esempio /var/log/auth.logdove non si sarebbe mescolato nei miei registri delle applicazioni. Per rimuovere la registrazione sudo, ho aggiunto quanto segue in /etc/sudoers.d/10_myusermodo che assomigli a:
Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping
YMMV, se ritieni che disabilitare la registrazione crei problemi con i controlli di sicurezza, potresti anche provare a risolverlo tramite i filtri rsyslog.
session closed for user roote se lo filtro infatti sto filtrando tutti i messaggi. Voglio un utente specifico che non è menzionato nel messaggio e non posso filtrare in base al nome ...