False insecure memory warnings...

David Shaw dshaw@jabberwocky.com
Fri Apr 4 23:31:01 2003


--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 04, 2003 at 01:59:55PM -0500, gabriel rosenkoetter wrote:
> On Fri, Apr 04, 2003 at 12:51:42PM -0500, David Shaw wrote:
> > Very interesting.  There are a few other reasons that GnuPG might be
> > unable to get secure memory.  Being not setuid root (on those
> > platforms that need it) is only the most common.
>=20
> What is GnuPG's definition of "secure memory"? Does it have to be
> wired kernel memory (to avoid being paged)?
>=20
> I really hope that NetBSD's sysctls for this didn't change between
> 1.5 and 1.6; it'll harm binary package compatibility.
>=20
> > What happens if you run this program out of cron in the same way
> > (zsh -c 'time testprog').

[ not that either ]

> So euid isn't the problem, then.
>=20
> Back to "what's GnuPG do to secure memory"? (Pointing me at the
> right source file would be plenty...)

util/secmem.c.  In particular see lock_pool().

I wonder if the BSD login.conf rlimit stuff might be biting you here.
If cron has a smaller "memorylocked" value than you do when running
=66rom the shell, then the mlock call can fail and cause the symptoms
you see.  I do know there was a change to the NetBSD cron recently to
have it start using login_cap, but I don't know what release that was
in.

David

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2rc1 (GNU/Linux)
Comment: http://www.jabberwocky.com/david/keys.asc

iD8DBQE+jfm74mZch0nhy8kRAjnCAJ4kvmnmus1WrPWTbDR9HHIwPv+EKQCaAmL1
ZJCv0eyt19WuKJhaKA9zgJo=
=vPS7
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--