Mailing List Archive

Conflict with SSL
Hi All,

I've set up GnuPG on a web site hosted remotely by the mammoth Verio
web hosting company. A Perl script I wrote issues commands through a
form to the gpg executable for encryption and decryption. (For an
industrial-strength interface with GnuPG, please see Frank Tobin's
GnuPG-Interface module at http://GnuPG-Interface.sourceforge.net/.)
If the form is submitted without SSL, GnuPG works fine. However, if
the form is submitted under SSL, I get the following error message:

gpg: failed to create temporary file
`/www69/web/myaccount/cgi-local/.gnupg/.#lk100d2918.www69.22793859':
Permission denied
gpg: fatal: /www69/web/myaccount/cgi-local/.gnupg/trustdb.gpg: can't
create lock
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/16384

I'm using the server's shared certificate for SSL. I've
double-checked the paths and they're correct. (My script ran fine
without GnuPG.) In a post to one of Verio's mailing lists, I read
that someone had the same problem with PGP. The source of the problem
was apparently related to file/directory permissions that only the
superuser could change. Unfortunately, the person making the post is
long gone from Verio and the first line of tech support is a bit
baffled. Is there a way around this obstacle?

Thanks,
Mark Malkasian
-------------------------
Mark Malkasian
mark@web-crafter.net
http://www.web-crafter.net
Re: Conflict with SSL [ In reply to ]
Mark Malkasian, at 09:45 -0400 on Fri, 5 May 2000, wrote:

> gpg: failed to create temporary file
> `/www69/web/myaccount/cgi-local/.gnupg/.#lk100d2918.www69.22793859':
> Permission denied

Try using GnuPG's homedir option to decide where its home directory (and
subsequently where it tries to write to).

On a side note, I think that this situation shows the need for a separate
option in GnuPG, say tempdir, which decides which directory GnuPG uses for
its temporary files. This can be very useful in instances where the home
directory is read-only, but temporary files still need to be created.

--
Frank Tobin http://www.uiuc.edu/~ftobin/

"To learn what is good and what is to be valued,
those truths which cannot be shaken or changed." Myst: The Book of Atrus
Re: Conflict with SSL [ In reply to ]
>[Friday, 05/05/2000] Mark Malkasian:
> > gpg: failed to create temporary file
> > `/www69/web/myaccount/cgi-local/.gnupg/.#lk100d2918.www69.22793859':
> > Permission denied
> > gpg: fatal: /www69/web/myaccount/cgi-local/.gnupg/trustdb.gpg: can't
> > create lock
> > secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/16384
> >
>My guess is that your CGI script runs under a different UID with and
>without SSL.
>
>A possible solution: find out what UID the CGI script runs under SSL
>(I wouldn't be surprised if it where 'nobody') and make your trustdb.gpg
>file readable/writable by that UID, just before issuing the GPG command
>(and restoring its permissions after the command finishes)
>
>Good luck.


You were definitely on the right track. I needed to change the
ownership of the gpg executable, configuration files, and the
directory in which they're stored, as well as the directory holding
the encrypted files, to "web".

For ex.,
$how_many = chown ("202", "103 103", "$root/cgi-local/.gnupg",
$root/cgi-local/. gnupg/gpg", etc);

Of course, the permissions for the directory to which encrypted files
are written has to be 0777.

Thanks,
Mark Malkasian

-------------------------
Mark Malkasian
mark@web-crafter.net
http://www.web-crafter.net
Re: Conflict with SSL [ In reply to ]
> Frank Tobin (Fri 05.0500-19:45):

> On a side note, I think that this situation shows the need for a separate
> option in GnuPG, say tempdir, which decides which directory GnuPG uses for
> its temporary files. This can be very useful in instances where the home
> directory is read-only, but temporary files still need to be created.

yes. furthermore, one needs to put gnupg's tmp-files where no gangster can
get at'em.

--
ino-waiting@gmx.net
Re: Conflict with SSL [ In reply to ]
> Mark Malkasian (Fri 05.0500-21:42):

> Of course, the permissions for the directory to which encrypted files
> are written has to be 0777.

you might want to set the sticky bit. that way, only accounts which
created files can purge them.

--
ino-waiting@gmx.net