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--