-
-
Save oseme-techguy/bae2e309c084d93b75a9b25f49718f85 to your computer and use it in GitHub Desktop.
#!/usr/bin/env bash | |
# To fix the " gpg: WARNING: unsafe permissions on homedir '/home/path/to/user/.gnupg' " error | |
# Make sure that the .gnupg directory and its contents is accessibile by your user. | |
chown -R $(whoami) ~/.gnupg/ | |
# Also correct the permissions and access rights on the directory | |
chmod 600 ~/.gnupg/* | |
chmod 700 ~/.gnupg |
Thank you for documenting this and for the updated answer @kirvedx worked perfectly 👍
@kirvedx Thanks for documenting this :)
@kirvedx Thanks for sharing. Your approach is what worked for me. Thanks!
One command.
chmod -R u=rw,u+X,go= ~/.gnupg/
@AnrDaemon , why u=rw,u+X
, shouldn't just u=rwX
do the same thing?
I'm using this, and it seems to work correctly, and has proper quoting to make shellcheck
happy. It even creates the directory if it doesn't exist, because in my case this is part of an automated script that I use to set up new computers (so it's possible this is the first time running GnuPG):
mkdir -p "$HOME/.gnupg/"
chown -R "$(whoami)" "$HOME/.gnupg/"
chmod -R u=rwX,go= "$HOME/.gnupg/"
X sets executable bit if a file is a directory or already executable. When you want to RESET executable bit but keep directories accessible, you first clear everything unwanted (u=rw,…
), then set correct bits for directories (…,u+X
).
I'm using this, and it seems to work correctly
Only as long as it has no wrongly +x'd files.
Ah, right, that makes sense. In this case using u+X
is probably better, but in a general case it's probably better not to wipe the executable bits for files that already have them.
:) In a general case, there's no general case, you do what needs to be done.
In my case, I often need to clear unnecessary +x set by Windows systems accessing directory over Samba share.
Line 8 changes the permissions on the files in the ~/.gnupg/* directory to 700. 700 means that only the owner/creator can Read, Write and Execute on the files in the directory. Also group and others cannot perform any operation on the files in the directory.
Permissions on a directory are a bit different than for a file. Read on a directory allows you to list the directory contents. Write allows you to create or delete files in the directory. Execute allows you to access files or directories in the directory (i.e., open them). Execute without read is allowed, so you can open files if you know their pathnames even though you cannot list the contents of the directory.
Yes, what @Eric-Catalyst says is correct.
Thanks guys. Thanks @AnrDaemon. I incorporated those changes, in my case looks like I just mkdir
first so ownership is fine, I just need to change file/folder permissions.
Then I just add:
chmod -R u=rw,u+X,go= ~/.gnupg
I hope that's compatible on various OS, like Mac/Linux etc. Should be, right? Anyway, here's the repo I added that changes to. It has a script to simplify set up of SSH and GPG stuff on a new mac. Hope it helps someone else out, let me know if so.
I seem to be the odd one out for this, I just installed ezarcher and I've tried everyone's suggestions. Not one of them worked for me. When I run ls - la or -ld it says that I'm the owner of /.gnupg. but when I try to run anything with sudo like pacman-key --init I get "gpg: WARNING: unsafe permissions on homedir '/root/.gnupg' ". I even did the gpgconf --kill all and gpgconf --kill dirmngr. I'm hope that someone e has come up with another option by now
Thank
Aunt13
sudo
without an explicit user specification defaults to user #0
(usually named root
).
Please show an actual output of sudo getfacl /root/.gnupg
for further diagnostics.
thanks alot for this