Início / server / Perguntas / 1177835
Accepted
Diagon
Asked: 2025-03-28 07:29:23 +0800 CST

sudoers: trabalhando para um usuário, mas não para outro

  • 772

Estou no Ubuntu 22.04 e tenho o seguinte arquivo sodoers para o usuário btrbk, localizado em /etc/sudoers.d/btrbk, que funciona bem:

Cmnd_Alias BTRFS_FILESYSTEM_USAGE = /usr/bin/btrfs filesystem usage *
Cmnd_Alias BTRFS_SUBVOLUME_SHOW = /usr/bin/btrfs subvolume show *
Cmnd_Alias BTRFS_SUBVOLUME_LIST = /usr/bin/btrfs subvolume list *
Cmnd_Alias BTRFS_SUBVOLUME_SNAP = /usr/bin/btrfs subvolume snapshot *
Cmnd_Alias BTRFS_SUBVOLUME_DELETE = /usr/bin/btrfs subvolume delete *
Cmnd_Alias BTRFS_SEND = /usr/bin/btrfs send *
Cmnd_Alias BTRFS_RECEIVE = /usr/bin/btrfs receive *
Cmnd_Alias READLINK = /usr/bin/readlink *
Cmnd_Alias TEST = /usr/bin/test *

btrbk ALL= NOPASSWD: BTRFS_FILESYSTEM_USAGE, BTRFS_SUBVOLUME_SHOW, BTRFS_SUBVOLUME_LIST, BTRFS_SUBVOLUME_SNAP, BTRFS_SUBVOLUME_DELETE, BTRFS_SEND, BTRFS_RECEIVE, READLINK, TEST

Por outro lado, tenho o seguinte para o usuário dev, localizado em /etc/sudoers.d/dev, a maior parte do qual é um subconjunto do para btrbk, mas todos estão falhando:

Cmnd_Alias BTRFS_FILESYSTEM_SHOW_DEV = /usr/bin/btrfs filesystem show *
Cmnd_Alias BTRFS_FILESYSTEM_USAGE_DEV = /usr/bin/btrfs filesystem usage *
Cmnd_Alias BTRFS_SUBVOLUME_SHOW_DEV = /usr/bin/btrfs subvolume show *
Cmnd_Alias BTRFS_SUBVOLUME_LIST_DEV = /usr/bin/btrfs subvolume list *

Cmnd_Alias TRANSMISSION_RESTART_DEV = /usr/bin/systemctl restart transmission-daemon.service

dev ALL= NOPASSWD: BTRFS_FILESYSTEM_SHOW_DEV, BTRFS_FILESYSTEM_USAGE_DEV, BTRFS_SUBVOLUME_SHOW_DEV, BTRFS_SUBVOLUME_LIST_DEV
dev ALL= NOPASSWD: TRANSMISSION_RESTART_DEV

O arquivo /etc/soderstem o devido

@includedir /etc/sudoers.d

E, as permissões para sudoerse sudoers.d/*são 440 com o proprietário root. sudo -lU btrbkA saída comparada com a de devparece estar correta:

$ sudo -l -U btrbk
Matching Defaults entries for btrbk on ThinkPad:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User btrbk may run the following commands on ThinkPad:
    (root) NOPASSWD: /usr/bin/btrfs filesystem usage *, /usr/bin/btrfs subvolume show *, /usr/bin/btrfs subvolume list *, /usr/bin/btrfs
        subvolume snapshot *, /usr/bin/btrfs subvolume delete *, /usr/bin/btrfs send *, /usr/bin/btrfs receive *, /usr/bin/readlink *,
        /usr/bin/test *

$ sudo -l -U dev
Matching Defaults entries for dev on ThinkPad:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User dev may run the following commands on ThinkPad:
    (ALL : ALL) ALL
    (root) NOPASSWD: /usr/bin/btrfs filesystem show *, /usr/bin/btrfs filesystem usage *, /usr/bin/btrfs subvolume show *, /usr/bin/btrfs subvolume
        list *
    (root) NOPASSWD: /usr/bin/systemctl restart transmission-daemon.service

Para o usuário dev, o btrfs apresenta falhas de permissão:

$ btrfs filesystem show
ERROR: cannot open /dev/mapper/luks.root: Permission denied
ERROR: cannot open /dev/mapper/ub.luks.root: Permission denied
ERROR: cannot open /dev/mapper/luks.data: Permission denied
ERROR: cannot open /dev/mapper/sd.luks.backup: Permission denied

Da mesma forma para a transmissão, que abre uma janela para autenticação, que quando cancelada...

$ systemctl restart transmission-daemon.service 
Failed to restart transmission-daemon.service: Access denied
See system logs and 'systemctl status transmission-daemon.service' for details.

$ journalctl -x -b0 | grep transmission | tail -n1
Apr 03 15:38:53 ThinkPad polkitd(authority=local)[2612]: Operator of unix-session:3 FAILED to authenticate to gain authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.1042 [systemctl restart transmission-daemon.service] (owned by unix-user:dev)

Alguém pode dar sugestões sobre o porquê disso acontecer?

sudo

1 respostas

  1. Best Answer

    sudoO comando deve ser especificado explicitamente antes do outro comando para ser executado com privilégios elevados/de outro usuário.

    /etc/sudoerscontrola apenas quem pode usar sudo, com quais comandos e em quais sistemas. Ele não faz "magicamente" com que os comandos de destino iniciem o sudocomando em nome do usuário.

    • 1

relate perguntas