Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I run logcheck on my Debian Linux system to get alerted to unusual lines in my log files, and recently I saw the following in /var/log/messages:

gnome-keyring-daemon: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

I don't know exactly what caused the message, just noticed it later in the logs. What does this mean, and how can I fix it?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

Gnome-keyring-daemon is failing to allocate memory that cannot be swapped out (that's what it calls “secure memory”). The reason it tries to do that is that writing sensitive data (passwords or keys) to swap is a risk. It's only a risk against a specific threat, though: the threat that someone will steal your disk, but not your powered-on computer. It's irrelevant if you have no swap space or encrypt your swap space. It's also irrelevant if your computer is in a physically secure location. It is relevant if your computer is a laptop and you're worried about an unsophisticated thief, but unsophisticated thieves tend to care about your laptop's resale value and not your passwords (however, there is a burgeoning market for resale of corporate passwords). If you're worried about sophisticated thieves, you should be encrypting your confidential data and your swap space anyway.

Allocating memory that cannot be swapped out is done by the mlock system call, which locks a memory page at its present physical location. This requires privileges because otherwise an application could saturate the RAM. Under Linux, the appropriate privilege is the CAP_IPC_LOCK capability. Under Solaris, it's PRIV_SYS_CONFIG.

Under Linux, any process can lock a small amount of memory, determined by the RLIMIT_MEMLOCK limit. Under most shells, ulimit -l will show how much memory each unprivileged process may lock (in kB). If the limit is 0, check whether it's a hard limit (imposed by root, listed with ulimit -Hl) or a soft limit (self-imposed, listed by ulimit -Sl). You can raise the soft limit up to the hard limit with e.g. ulimit -l 64. To raise the hard limit, edit /etc/security/limits.conf (the syntax is documented in the file); this file is read when you log in.

TL,DR: it's a security feature, which you probably don't care about. Don't sweat it.

share|improve this answer

I also got:

Oct 20 22:43:28 gnome-keyring-daemon[13543]: Gkm: using old keyring directory: /home/sergio/.gnome2/keyrings
Oct 20 22:43:28  gnome-keyring-daemon[13543]: Gkm: using old keyring directory: /home/sergio/.gnome2/keyrings
Oct 20 22:49:13  gnome-keyring-daemon[13543]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

I remove .gnome2/keyrings , and lost all my passwords but gnome created a new directory with keyrings in .local/share/keyrings, and warnings disappear .

you can edit the passwords with command seahorse

I had a few passwords so I don't mind , but once I move .gnome2/keyrings directory I never get back my passwords. And solve the problem

share|improve this answer
1  
downvoted because the solution causes loss of data when it actually isn't a big deal (see Gilles' answer). additionally, i suspect that this will fix a symptom, not the root cause. –  strugee Oct 21 '13 at 2:31
    
no , you should migrate gnome-keyring, I just don't know how , and I warn that data will be lost . –  Sérgio Oct 22 '13 at 3:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.