Baseado na resposta de Toby, eu encontrei uma maneira de configurar isso de uma maneira um pouco diferente no Debian / Ubuntu. Para o contexto, consulte:
Portanto, o Debian / Ubuntu tem este pam-auth-updatecomando e, quando você olha /etc/pam.d/sudo, fica assim:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
e /etc/pam.d/common-session-noninteractivefica assim:
#
# /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
Então, com certeza, eu poderia editar qualquer um dos arquivos acima, mas claramente há um "poder superior" em ação aqui. Como fazer minhas alterações funcionarem bem com outros pacotes que podem querer adicionar regras do pam? Ainda por cima, parecia que eu não poderia simplesmente adicionar uma linha /etc/pam.d/sudoentre os dois @includesegundos assim.
##### 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
Depois de ler os links acima, bem como outros exemplos (consulte /usr/share/pam-configs/unix), vim com isso, em /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-Typecontrolar quais arquivos são editados e Prioritydefine em que ordem eles entram. Depois de adicionar esse arquivo e executá-lo pam-auth-update, /etc/pam.d/common-session-noninteractivefica assim (na parte inferior :)
#... 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
... o que queremos, porque nossa pam_succeed_iflinha precisa vir antes session required pam_unix.so. (Essa linha vem /use/share/pam-configs/unixe tem um, Priority: 256então termina em segundo.) Observe também que deixei o service = sudopredicado, pois common-session-noninteractivetambém pode ser incluído em outras configurações sudo.
No meu caso, eu já tinha embalado meu código como um instalador .deb então eu adicionei o /usr/share/pam-configs/myapparquivo, e acrescentou pam-auth-update --packageaos meus postinste prermroteiros e eu sou bom para ir!
Embargo...
Se você ler o artigo PAMConfigFrameworkSpec vinculado acima , ele definirá uma Session-Interactive-Onlyopção, mas não poderá especificar apenas regras não interativas . Então também/etc/pam.d/common-session foi atualizado . Eu não acho que há uma maneira de contornar isso. Se você concorda que as sessões interativas não estão sendo registradas para esse usuário (é uma conta de serviço, certo?), Você deve estar pronto!
Bônus: como remover também a saída do log do sudo
Além das session openened|closedlinhas que o PAM emite, sudoregistra informações adicionais sobre o comando executado. Se parece com isso:
[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...
Se você também deseja remover isso, abra este link e continue abaixo ...
Então ... você provavelmente conhece a /etc/sudoers.d/___configuração típica, que pode fazer algo assim para uma conta de serviço que precisa de privilégios de superusuário para algumas ações:
myuser ALL=(ALL) NOPASSWD: /bin/ping
que pode entrar /etc/sudoers.d/10_myuser. Bem, entre outras coisas, você também pode especificarDefaults . Observe especificamente esta sintaxe'Defaults' ':' User_List
Agora, veja a seção SUDOERS OPTIONS . Bits interessantes incluem log_input, log_outputmas (provavelmente) mais importante, sysloge logfile. Parece-me que nas versões recentes do Debian, rsyslog ou sudolog para stdoutou stderrpor padrão. Então, para mim, isso estava aparecendo no log de diário do meu serviço, e não por exemplo, /var/log/auth.logonde não seria misturado nos logs de aplicativos. Para remover o registro do sudo, adicionei o seguinte ao seguinte /etc/sudoers.d/10_myuser:
Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping
YMMV, se você sentir que desabilitar o log cria problemas com as auditorias de segurança, você também pode tentar resolver isso por meio de filtros rsyslog.
session closed for user roote se eu filtrar de fato, estou filtrando todas as mensagens. Quero para um usuário específico que não é mencionado na mensagem e eu não posso filtrar por seu nome ...