Le samedi 26 janvier 2013 à 02:46 -0500, Mike Frysinger a écrit :
> On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote:
> > It's not like libcap is a big dependency
>
> true, but not everyone needs this, nor can everyone leverage it (caps). it's
> a linux-centric implementation and i
On 27.01.2013 18:26, Mike Frysinger wrote:
> On Friday 25 January 2013 18:51:44 Mike Frysinger wrote:
>> i've taken Constanze' work and rewritten it a bit to be easier to use (imo)
>> as most settings are now defaults
>
> merged. i'll move iputils over to it first and if there aren't any problems
On Friday 25 January 2013 18:51:44 Mike Frysinger wrote:
> i've taken Constanze' work and rewritten it a bit to be easier to use (imo)
> as most settings are now defaults
merged. i'll move iputils over to it first and if there aren't any problems,
i'll move more over to it.
-mike
signature.asc
On Fri, Jan 25, 2013 at 5:51 PM, Mike Frysinger wrote:
> i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
> most settings are now defaults
> -mike
>
Good deal. Good idea on using USE=filecaps instead of USE=caps due to
the requirements. Once this hits the tree I'll l
On Saturday 26 January 2013 08:21:37 Michał Górny wrote:
> On Fri, 25 Jan 2013 18:51:44 -0500 Mike Frysinger wrote:
> > # Or set it via the global ebuild var FILECAPS:
> > # @CODE
> > # FILECAPS=(
> > # cap_net_raw bin/ping bin/ping6
> > # )
> > # @CODE
>
> Please don't. We have enough eclasses
On 26/01/2013 17:13, Rich Freeman wrote:
> I naively assumed that if you edit /etc/security/capability.conf this
> would set the per-user capabilities. However, I have not actually
> tried this. I guess our pam configuration/etc isn't set to check this
> file?
pambase is not enabling pam_caps, s
On Sat, Jan 26, 2013 at 11:01 AM, Diego Elio Pettenò
wrote:
>
> There's also a different kind of capabilities, in theory, relating to
> users instead and using PAM — but I never got to get it working :(
I naively assumed that if you edit /etc/security/capability.conf this
would set the per-user c
On 26/01/2013 08:46, Mike Frysinger wrote:
>
> at least, this is all my understanding of things. i could be completely
> wrong, so feel free to correct something if you notice it.
All looks good to me, but just because somebody is going to wonder this
I would add a few words:
While this is bas
On Fri, 25 Jan 2013 18:51:44 -0500
Mike Frysinger wrote:
> # Or set it via the global ebuild var FILECAPS:
> # @CODE
> # FILECAPS=(
> # cap_net_raw bin/ping bin/ping6
> # )
> # @CODE
Please don't. We have enough eclasses randomly exporting
pkg_postinst().
The FILECAPS array consumes the sam
On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote:
> It's not like libcap is a big dependency
true, but not everyone needs this, nor can everyone leverage it (caps). it's
a linux-centric implementation and is dependent upon filesystem support being
available & enabled.
that doesn'
On 26/01/2013 01:10, Gilles Dartiguelongue wrote:
> If the USE flag must stay, how is it different that current caps USE
> flag ? It applies and not just enables support but is that relevant to
> the purpose at hand ?
filecaps require the kernel to support security xattrs on the
filesystems used f
This might be a silly question already answered in a previous thread,
but why make it filecaps a USE-enable capability at all ?
It's not like libcap is a big dependency and it's not like this is an
attempt to make the system more secure by according just the privileges
needed for apps to work as i
i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
most settings are now defaults
-mike
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fcaps.eclass
# @MAINTAINER:
# Constanze Hausner
#
13 matches
Mail list logo
