Quoting Andrew Morgan ([EMAIL PROTECTED]):
Andrew Morgan wrote:
Serge E. Hallyn wrote:
0. fix the implementation of cap_setpcap. It is supposed to mean 'this
process can raise capabilities, outside its permitted set, in _its own_
inheritable set'.
I believe the attached patch does
Casey Schaufler wrote:
--- Joshua Brindle [EMAIL PROTECTED] wrote:
Since unprivileged programs (the origin, guard, and publication
daemons in smackguard run without privilege) can't change their
Smack labels establishing a pipe between processes with different
labels is not possible without
--- Joshua Brindle [EMAIL PROTECTED] wrote:
Casey Schaufler wrote:
--- Joshua Brindle [EMAIL PROTECTED] wrote:
Since unprivileged programs (the origin, guard, and publication
daemons in smackguard run without privilege) can't change their
Smack labels establishing a pipe between
Andrew, James, Stephen, Chris,
The following is all-but-untested (just compiles with relevant config
combinations). But is each of you ok with the following approach for
handling unknown capabilities?
KaiGai, the following does not require any immediate change from
libcap, but does dictate how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Andrew, James, Stephen, Chris,
The following is all-but-untested (just compiles with relevant config
combinations). But is each of you ok with the following approach for
handling unknown capabilities?
I'd prefer a
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Andrew, James, Stephen, Chris,
The following is all-but-untested (just compiles with relevant config
combinations). But is each of you ok with the following approach for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
So far as I can see there are two types of issue:
- a new capability comes along - it is needed to run an app
As an example, CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL were
added along with new features they control.
