Início / user-206680

Diagon's questions

Martin Hope
Diagon
Asked: 2025-03-28 07:29:23 +0800 CST
  • 5

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
Martin Hope
Diagon
Asked: 2019-08-10 17:37:48 +0800 CST
  • 0

No Debian, sou capaz de desbloquear vários discos na inicialização com apenas um prompt, usando decrypt_keyctl e a opção initramfs em /etc/crypttab. Eu estou querendo saber como fazer isso no CentOS-7?

Uma instalação simples do Nethserver com dois dispositivos luks tem um crypttab semelhante a este:

luks_root   UUID=<uuid1>   none
luks_swap   UUID=<uuid2>   none

Eu gostaria de adicionar outro disco. (E como é que a inicialização atual acontece com apenas um prompt de senha, quando há dois dispositivos?)

centos7
Martin Hope
Diagon
Asked: 2015-10-13 03:29:32 +0800 CST
  • 1

Eu tenho um disco contendo (apenas) um volume criptografado LUKS. Isso foi criado em uma unidade vazia sem tabela de partição usando cryptsetup v.1.6.1. Quando desbloqueado, posso verificar o tamanho do volume descriptografado, compará-lo com o disco inteiro e ver que a diferença é exatamente 2 MB. Quando faço backup do cabeçalho, por outro lado, usando:

cryptsetup luksHeaderBackup /dev/sda --header-backup-file <filename>

Recebo um arquivo com 30 kB a menos de 2 MB. Usando dd para despejar os primeiros 2 MB do disco e comparando-o com o cabeçalho de backup, vejo que faltam 30 KB no final e contém todos os 0s. Estranhamente, tenho backups de vários (outros) cabeçalhos LUKS usando cryptsetup 1.4.1 e 1.4.3, e todos eles têm exatamente 2 MB. Isso é consistente com a seção 6.2 do FAQ do cryptsetup , que diz que o tamanho do cabeçalho deve ser de 2 MB.

Alguém poderia me ajudar a entender o que são esses 30KB? (Gostaria de substituir o cabeçalho com dados aleatórios, pois o coloquei em um dispositivo separado e quero ter certeza de que sei o que estou fazendo.)

Também como uma questão mais geral, existe uma maneira mais fácil/automatizada, usando a saída do luksDump talvez, para dizer exatamente onde o cabeçalho está localizado em um disco? (Deslocamento e tamanho.) Eu li as perguntas frequentes do cryptsetup, mas o resultado certamente não desaparece.

E existe uma maneira melhor de substituir o cabeçalho do que usar dd?

cryptsetup luksHeaderRestore <file_with_random_data>

não funciona, porque o cryptsetup faz algumas verificações idiotas para ver se algum cabeçalho já presente corresponde ao tamanho da chave mestra e ao deslocamento.

luks