Please: someone help fix this! guru wanted!
Tue May 8 06:13:01 2001
This is the third time I'm asking this... thanks to the people who
tried helping. It seems that gpg STILL requires write perms on trustdb.
I need my CGI to encrypt some data with my public key. I
don't want the CGI (user apache, group apache) to require
write permissions on ANY file in order to do the encryption,
as I don't want any old CGI process to corrupt my files.
I was using pgp2.6.3 and that always required randseed.bin
to be writable.
I switched to gpg1.0.4 thinking that --no-random-seed-file
would do the trick. But after experimenting it seems that
instead trustdb.gpg needs to be writable no matter what!
That's simply trading between two evils!
Is there a way I can invoke gpg so that it will work with
NO write perms on ANY files or directories?
Here's what my command line looks like now:
gpg -ea -z9 -r'Web Site Name' --always-trust --lock-never --batch
> Try the following:
> gpg -ea -z9 -r'Web Site Name' --always-trust --lock-never --batch
> --no-random-seed-file ----trusted-key=Web_Site_Name_s_long_ID
> where Web_Site_Name_s_long_ID is the 5th field of the last row produced by
> gpg --list-keys --with-colons 'Web Site Name'
I thought about that option, but I didn't know how to get the "long
But I tried it now and it STILL tries to write to trustdb :-(
Here's my command line:
% su - nobody
% gpg -ea -z9 -r'WebSiteName' --always-trust --lock-never --batch
gpg: Warning: using insecure memory!
gpg: fatal: /work/who/web/.gpg/trustdb.gpg: can't open: Permission denied
% ls -al /work/who/web/.gpg
drwxr-xr-x 2 trevor trevor 4096 Mar 28 14:51 .
drwxrwxrwx 15 trevor trevor 8192 Mar 27 23:01 ..
-rw-r--r-- 1 trevor trevor 869 Mar 27 13:37 pubring.gpg
-rw-r--r-- 1 trevor trevor 0 Mar 27 13:35 pubring.gpg~
-rw-r--r-- 1 trevor trevor 600 Mar 27 13:37 random_seed
-rw-r--r-- 1 trevor trevor 1091 Mar 27 13:37 secring.gpg
-rw-r--r-- 1 trevor trevor 2560 Mar 27 14:06 trustdb.gpg
Obviously everything works peachy if I execute this as trevor. But my
web server will eventually run this as apache:apache, so it has to work
for other (non)users.