Why is OpenSSL able to use a key file my user shouldn't have access to? - Lemmy.ca

The following command works even though I really don’t think I should have permission to the key file: $ openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/etcBackup.key I’m unable to even ascertain the existence of the key file under my normal user. I’m a member of only two groups, my own group and vboxusers. The permissions leading up to that file: drwxr-xr-x 1 root root 4010 Jul 31 08:01 etc ... drwxr-xr-x 1 root root 206 Jul 14 23:52 ssl ... drwx------ 1 root root 26 Jul 31 14:07 private ... -rw------- 1 root root 256 Jul 31 14:07 etcBackup.key OpenSSL isn’t setuid: > ls -la $(which openssl) -rwxr-xr-x 1 root root 1004768 Jul 14 23:52 /usr/bin/openssl There don’t appear to be any ACLs related to that key file: > sudo getfacl /etc/ssl/private/etcBackup.key [sudo] password for root: getfacl: Removing leading '/' from absolute path names # file: etc/ssl/private/etcBackup.key # owner: root # group: root user::rw- group::--- other::--- > sudo lsattr /etc/ssl/private/etcBackup.key ---------------------- /etc/ssl/private/etcBackup.key Finally, it’s not just the case that the original file was encrypted with an empty file: > openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/abc.key bad decrypt 4047F634B67F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:providers/implementations/ciphers/ciphercommon_block.c:124 Does anyone know what I’ve missed here?