-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've pushed it to a pamcap-enhancements branch and I'll will try to
review it quickly.
Thanks
Andrew
KaiGai Kohei wrote:
> Sorry, any TABs are replaced by MUA.
> I'll send the patch again.
>
>> The attached patch provides several improvement for pa
Sorry, any TABs are replaced by MUA.
I'll send the patch again.
> The attached patch provides several improvement for pam_cap module.
> 1. It enables pam_cap to drop capabilities from process'es capability
>bounding set.
> 2. It enables to specify allowing inheritable capability set or droppin
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
BTW, could you tell me your intention about pam_cap.c is implemented
with pam_sm_authenticate() and pam_sm_setcred()?
I think it can be done with pam_sm_open_session(), and this approach
enables to reduce the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> BTW, could you tell me your intention about pam_cap.c is implemented
> with pam_sm_authenticate() and pam_sm_setcred()?
> I think it can be done with pam_sm_open_session(), and this approach
> enables to reduce the iteration of re
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
+if (!!cap_issubset(*inheritable,
+ cap_combine(target->cap_inheritable,
+ cur
(Thus, the correct check says no 'new' pI bits can be outside cap_bset.)
If this condition intends to dominate 'new' pI bits by 'old' pI bits masked
with bounding set, we should not apply cap_combine() here.
I think applying cap_intersect() is correct for the purpose.
That would have been my fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
+if (!!cap_issubset(*inheritable,
+ cap_combine(target->cap_inheritable,
+ c
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> KaiGai Kohei wrote:
>>> Serge,
>>>
>>> Please tell me the meanings of the following condition.
>>>
diff --git a/security/commoncap.c b/security/commoncap.c
index 3a95990
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
Serge,
Please tell me the meanings of the following condition.
diff --git a/security/commoncap.c b/security/commoncap.c
index 3a95990..cb71bb0 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Serge,
>
> Please tell me the meanings of the following condition.
>
>> diff --git a/security/commoncap.c b/security/commoncap.c
>> index 3a95990..cb71bb0 100644
>> --- a/security/commoncap.c
>> +++ b/security/commoncap.c
>> @@
Serge,
Please tell me the meanings of the following condition.
diff --git a/security/commoncap.c b/security/commoncap.c
index 3a95990..cb71bb0 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -133,6 +119,12 @@ int cap_capset_check (struct task_struct *target,
kernel_cap_t *effec
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [I've droped lkml]
>
> KaiGai Kohei wrote:
> >> But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand
> >> this line means any capabilities except for cap_xxx.
>
> I like '!', but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[I've droped lkml]
KaiGai Kohei wrote:
>> But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand
>> this line means any capabilities except for cap_xxx.
I like '!', but you're going to code it... ;-) I can live with b:.
>> Thus, I
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
I think it is a good idea.
However, this module already have a feature to modify inheritable
capability set.
How do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
>> There is already a pam_cap module in the libcap2 package. Can we merge
>> this functionality?
>
> I think it is a good idea.
>
> However, this module already have a feature to modify inheritable
> capability set.
> How does it
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
I think it is a good idea.
However, this module already have a feature to modify inheritable
capability set.
How does it to be described in the "/etc/security/capability.conf"?
One idea is like a followi
Serge,
Is there any reason not to have a separate /etc/login.capbounds
config file, though, so the account can still have a full name?
Did you only use that for convenience of proof of concept, or
is there another reason?
passwd(5) says the fifth field is optional and only used for
information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
Cheers
Andrew
[EMAIL PROTECTED] wrote:
> Quoting KaiGai Kohei ([EMAIL PROTECTED]):
>> Serge E. Hallyn wrote:
>>> The capability bounding set is a set beyond w
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > The capability bounding set is a set beyond which capabilities
> > cannot grow. Currently cap_bset is per-system. It can be
> > manipulated through sysctl, but only init can add capabilities.
> > Root can remove capabilities.
Serge E. Hallyn wrote:
> The capability bounding set is a set beyond which capabilities
> cannot grow. Currently cap_bset is per-system. It can be
> manipulated through sysctl, but only init can add capabilities.
> Root can remove capabilities. By default it includes all caps
> except CAP_SETPCA
Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This looks good to me.
>
> [As you anticipated, there is a potential merge issue with Casey's
> recent addition of MAC capabilities - which will make CAP_MAC_ADMIN the
> highest allocated capability:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This looks good to me.
[As you anticipated, there is a potential merge issue with Casey's
recent addition of MAC capabilities - which will make CAP_MAC_ADMIN the
highest allocated capability: ie.,
#define CAP_LAST_CAP CAP_MAC_ADMIN
].
Signe
>From 22da6ccb1a24d1b6fa481d990a26197c6bfdfa77 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 13:54:05 -0500
Subject: [PATCH 1/1] capabilities: introduce per-process capability bounding
set (v10)
The capability bounding set is a set beyond which capabili
23 matches
Mail list logo
