| 1 |
Diego 'Flameeyes' Pettenò wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> I'd like to propose the rename of caps USE flag to libcap. The reason |
| 5 |
> for this is that I'd like to free the "caps" USE flag from the (runtime) |
| 6 |
> dependency of libcap, so that, one we have the framework to do so, we |
| 7 |
> could use the "caps' USE flag to set file capabilities directly (rather |
| 8 |
> than setuid for instance). |
| 9 |
As an example: the pwsafe app suggest you have to run it suid (since it |
| 10 |
tries to lock some memory to avoid swapping), but doing 'setcap |
| 11 |
cap_ipc_lock=ep /usr/bin/pwsafe' is enough. |
| 12 |
|
| 13 |
> The step right afterward would be, for me, to find a way to mirror the |
| 14 |
> capabilities from within Portage. I admit I have no clue how to achieve |
| 15 |
> that for now. But at least the rename is a simple task, and I suppose |
| 16 |
> the capabilities handling _could_ be a SoC project... |
| 17 |
|
| 18 |
Well, I'm not sure whether libcap is a good choice: What about |
| 19 |
(not-yet-existing) apps which provide capability-support through another |
| 20 |
package (like a foobar language libcap-wrapper)? Should they also use |
| 21 |
libcap then? |
| 22 |
|
| 23 |
|
| 24 |
-- |
| 25 |
gentoo-dev@l.g.o mailing list |
Archives