Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

use linux capabilities to set cap_ipc_lock #31

Closed
paolostivanin opened this issue Dec 25, 2017 · 1 comment
Closed

use linux capabilities to set cap_ipc_lock #31

paolostivanin opened this issue Dec 25, 2017 · 1 comment
Assignees
@paolostivanin
Labels
Status: Done Type: Bug

Comments

@paolostivanin
Copy link
Owner

  • setcap cap_ipc_lock=ep
  • remove "known issues" from readme
@paolostivanin paolostivanin self-assigned this Dec 25, 2017
@paolostivanin paolostivanin mentioned this issue Dec 25, 2017
Closed
@paolostivanin paolostivanin changed the title use linux capabilities for mlock usage use linux capabilities to set cap_ipc_lock Dec 25, 2017
@paolostivanin
Copy link
Owner Author

doesn't work with flatpak & co and, apparently, there's no way around it

paolostivanin added a commit that referenced this issue Dec 26, 2017
@paolostivanin
Use current memlock limit to define max_file_size
a414ebc 
When using Gcrypt's secure memory, the amount of needed memory must be
greater than the current memlock OS limit (ulimit -l). On some systems,
this value is very low (64 KB), thus causing the software to not even
start up.
A few possibilities were evaluated:
1. use setcap on installation phase: easy, but not achievable with
flatpak, appimage, and Co.
2. force the user to play with ulimit: cumbersome and absolutely not
user-friendly
3. set the max available secure memory to the current system memlock
value
Option 3 is the one that got implemented with this commit. This has a
small drawback though because if a user needs to store more than ~130
tokens, each one using very long (128 chars) label and issuer and long
(64 chars) secret, the user won't be able to do that, unless he/she does
something with either setcap or ulimit.

- fix #31
- update readme
- show a warning when memlock limit is less than 256KB
paolostivanin added a commit that referenced this issue Dec 26, 2017
@paolostivanin
Use current memlock limit to define max_file_size
c6c641a 
When using Gcrypt's secure memory, the amount of needed memory must be
greater than the current memlock OS limit (ulimit -l). On some systems,
this value is very low (64 KB), thus causing the software to not even
start up.
A few possibilities were evaluated:
1. use setcap on installation phase: easy, but not achievable with
flatpak, appimage, and Co.
2. force the user to play with ulimit: cumbersome and absolutely not
user-friendly
3. set the max available secure memory to the current system memlock
value
Option 3 is the one that got implemented with this commit. This has a
small drawback though because if a user needs to store more than ~130
tokens, each one using very long (128 chars) label and issuer and long
(64 chars) secret, the user won't be able to do that, unless he/she does
something with either setcap or ulimit.

- fix #31
- update readme
- show a warning when memlock limit is less than 256KB
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@paolostivanin paolostivanin

Labels
Status: Done Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@paolostivanin