Я понятия не имею о awk
, однако я знаю путь с shell
+sed
:
file='wot-;wit-;wet-;wat.txt';
echo -n "type digits : ";
read nos;
# this is used to sort numbers in order, otherwise the script
# will work only when user specifies numbers in right order
# also we delete all non-numbers string to make sed code safe enough
nos="$(echo $nos|tr ' ' '\n'|sort -n|grep -v '[^0-9]'|tr '\n' ' ')"
# here we build sed code and modify the text
echo "$file" | { for i in $nos ; do A="s/-/+/$i;$A" ; done ; sed "$A" ; }
Похоже, вы довольно близки со своей строкой конфигурации PAM:
session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0
Глядя на страницу руководства для pam_succeed_if
, я думаю, вы хотите проверьте, что запрашивающий пользователь ( ruser
) - это zabbix
.
Поэтому я предлагаю:
session [success=1 default=ignore] pam_succeed_if.so quiet uid = 0 ruser = zabbix
Это отменит следующий тест, когда пользователь zabbix
станет root
(но без других переходов). Я тестировал это с парой моих собственных пользователей.
Удалите тест uid = 0
из приведенного выше, если вы не хотите, чтобы zabbix
стал любым пользователем, а не только пользователем root.
Я удалил службу в тесте sudo
: это избыточно, учитывая, что эта строка находится в /etc/pam.d/sudo
.
Вы получите:
pam_succeed_if(sudo:session): unknown attribute "ruser"
с вашим ответом.
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
session [success=1 default=ignore] pam_succeed_if.so service in zabbix quiet use_uid
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
работает, но вы все равно получите:
pam_unix(sudo:session): session opened for user root by (uid=0)
в ваших журналах.
Según la respuesta de Toby, encontré una manera de configurar esto de una manera ligeramente diferente en Debian/Ubuntu. Para el contexto, ver:
Así que Debian/Ubuntu tiene este comando pam-auth-update
y cuando miras /etc/pam.d/sudo
se ve así:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
y /etc/pam.d/common-session-noninteractive
se ve así:
#
# /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
Claro, podría editar cualquiera de los archivos anteriores, pero claramente hay un "poder superior" en el trabajo aquí. ¿Cómo hacer que mis cambios funcionen bien con otros paquetes que podrían querer agregar reglas pam? Para colmo, parecía que no podía simplemente agregar una línea en /etc/pam.d/sudo
entre los dos @include
como este...
##### 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
Después de leer los enlaces anteriores, así como otros ejemplos (ver/usr/share/pam-configs/unix
)Se me ocurrió esto, en/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
Session
y Session-Type
controlan qué archivos se editan y Priority
define en qué orden van. Después de agregar ese archivo y ejecutar pam-auth-update
, /etc/pam.d/common-session-noninteractive
se ve así (en la 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
... que es lo que queremos porque nuestra línea pam_succeed_if
debe estar antes de session required pam_unix.so
. (Esa línea viene de /use/share/pam-configs/unix
y tiene un Priority: 256
por lo que termina en segundo lugar. )Tenga en cuenta también que dejé el predicado service = sudo
ya que common-session-noninteractive
también podría incluirse en otras configuraciones además de sudo
.
En mi caso, ya había empaquetado mi código como un instalador.deb, así que agregué el archivo /usr/share/pam-configs/myapp
y agregué pam-auth-update --package
a mis scripts postinst
y prerm
y ¡ya estoy listo!
Si lee el artículo PAMConfigFrameworkSpec que vinculé anteriormente , define una opción Session-Interactive-Only
, pero no tiene una forma de especificar solo reglas no interactivas . Entonces /etc/pam.d/common-session
fue también actualizado . No creo que haya una forma de evitar esto. Si está de acuerdo con que las sesiones interactivas no se registren para ese usuario (, ES una cuenta de servicio, ¿verdad? )¡entonces deberías estar listo!
Además de las líneas session openened|closed
que emite PAM, sudo
registra información adicional sobre el comando que se ejecuta. Se parece a esto:
[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...
Si también desea eliminar eso, abra este enlace y luego continúe a continuación...
Entonces... probablemente esté familiarizado con la configuración típica /etc/sudoers.d/___
que podría hacer algo como esto para una cuenta de servicio que necesita privilegios de superusuario para algunas acciones:
myuser ALL=(ALL) NOPASSWD: /bin/ping
que podría entrar /etc/sudoers.d/10_myuser
. Bueno, entre otras cosas también puedes especificarDefaults
. Tenga en cuenta específicamente esta sintaxis'Defaults' ':' User_List
Ahora, mire la sección OPCIONES DE SUDOERS . Los bits interesantes incluyen log_input
, log_output
pero (probablemente )más importante, syslog
y logfile
. Me parece que en versiones recientes de Debian, rsyslog o sudo
se registran en stdout
o stderr
de forma predeterminada. Entonces, para mí, esto aparecía en el registro de diario de mi servicio, y no, p. /var/log/auth.log
donde no se mezcle con los registros de mi aplicación. Para eliminar el registro de sudo, agregué lo siguiente a /etc/sudoers.d/10_myuser
para que se vea como:
Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping
YMMV, si cree que deshabilitar el registro crea problemas con las auditorías de seguridad, también puede intentar resolver esto a través de filtros rsyslog.
Войдите в систему как root, отредактируйте файл /etc/pam.d/sudo
и добавьте
session [success=1 default=ignore] pam_succeed_if.so quiet uid = 0 ruser = alice
где alice
— ваше имя пользователя. Это предотвратит открытие и закрытие сеанса журналов.
Чтобы предотвратить регистрацию команд, отредактируйте /etc/sudoers
и добавьте
Defaults:alice !logfile, !syslog
чуть выше этой линии alice ALL:(ALL) :ALL
.