-
Notifications
You must be signed in to change notification settings - Fork 37
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.
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
capng_get_caps_process vs sandbox #11
Comments
I would agree. The issue is that getcap does not provide the bounding set: It only deals with the 3 normal sets. Ye olde libcap leaves the bounding set up to the individual to work out. It does not treat it as an equal component to capabilities. I suppose a fallback for this could be created which iterates over prctl testing each bit with PR_CAPBSET_READ. This would take some 37 syscalls (today) to work out...which is why we try to use /proc/<pid>/status. But at least this will get the right answer. |
What I've ended up with is: which isn't pretty but seems to work. |
Commit a074f1b should fix this. |
Hi,
I've got a heavily sandbox'd daemon that runs something like:
a) Sandbox
b) Create more threads
c) Do stuff in threads
The sandbox includes a mount namespace setup where it doesn't have /proc.
capng_get_caps_process calls get_bounding_set which reads /proc/.../state - which fails.
That's not a problem with yee oldee libcaps, it only uses capget.
So now I have a problem how to setup each thread; the current guess is to do a capng_save_state before the sandboxing, and then do a restore state somewhere in each thread.
Which is kind of OK except for restore_state freeing stuff; so I'm going to have to do a dance of restore_state/save_state to keep a copy.
It feels like there should be a better way.
The text was updated successfully, but these errors were encountered: