| 1 |
Le samedi 26 janvier 2013 à 02:46 -0500, Mike Frysinger a écrit : |
| 2 |
> On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: |
| 3 |
> > It's not like libcap is a big dependency |
| 4 |
> |
| 5 |
> true, but not everyone needs this, nor can everyone leverage it (caps). it's |
| 6 |
> a linux-centric implementation and is dependent upon filesystem support being |
| 7 |
> available & enabled. |
| 8 |
> |
| 9 |
> that doesn't entirely justify making it a USE flag (since the code already has |
| 10 |
> runtime fallback logic for when the fs doesn't support things), but since the |
| 11 |
> USE is low overhead and leverages logic that already has to be there, i have |
| 12 |
> no problem keeping it. plus it defaults to on. |
| 13 |
|
| 14 |
hum, ok. |
| 15 |
|
| 16 |
> > and it's not like this is an |
| 17 |
> > attempt to make the system more secure by according just the privileges |
| 18 |
> > needed for apps to work as intended, right ? |
| 19 |
> |
| 20 |
> mmm that's exactly what this is |
| 21 |
> |
| 22 |
> > If the USE flag must stay, how is it different that current caps USE |
| 23 |
> > flag ? It applies and not just enables support but is that relevant to |
| 24 |
> > the purpose at hand ? |
| 25 |
|
| 26 |
[...] |
| 27 |
|
| 28 |
In summary, USE=caps if for stripping down from all to the bare minimum |
| 29 |
caps while USE=filecaps should allow us to provide bare minimum required |
| 30 |
capabilities from the start. |
| 31 |
|
| 32 |
If so, maybe this could be the same USE flag ? I would understand if we |
| 33 |
wanted to keep it separated to avoid potential confusion about the |
| 34 |
actual impact on packages though. |
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
Gilles Dartiguelongue <eva@g.o> |
| 39 |
Gentoo |
Archives