like CAP_MAC_ADMIN
being #define'd then it won't be able to do things like cap_set_flag()
appropriately.
Cheers
Andrew
KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
>>> Remaining issue
like CAP_MAC_ADMIN
being #define'd then it won't be able to do things like cap_set_flag()
appropriately.
Cheers
Andrew
KaiGai Kohei wrote:
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
Remaining issues:
- We have to mount securityfs explicitly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Remaining issues:
> - We have to mount securityfs explicitly, or use /etc/fstab.
> It can cause a matter when we want to use this feature on
> very early phase on boot. (like /sbin/init)
I'm not altogether clear how you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
Remaining issues:
- We have to mount securityfs explicitly, or use /etc/fstab.
It can cause a matter when we want to use this feature on
very early phase on boot. (like /sbin/init)
I'm not altogether clear how you intend
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Andrew, I've cc:d you here bc in doing this patch I noticed that your
> 64-bit capabilities patch switched this code from an explicit check
> of cap_t(p->cap_effective) to using __capable(). That means that
> now being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Andrew, I've cc:d you here bc in doing this patch I noticed that your
64-bit capabilities patch switched this code from an explicit check
of cap_t(p-cap_effective) to using __capable(). That means that
now being glossed
-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
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> Question:
>>
>> The patch does the semantic equivalent of:
>>
>> -#define cap_clear(c) do { cap_t(c) = 0; } while(0)
>> -#define cap_set_full(c) do { cap_t(c) =
-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,
>>>>
-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,
+ current-cap_bset
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Question:
The patch does the semantic equivalent of:
-#define cap_clear(c) do { cap_t(c) = 0; } while(0)
-#define cap_set_full(c) do { cap_t(c) = ~0; } while(0)
-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
-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
@@ -133,6
-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
-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 to be
-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
-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 which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
I still feel a bit uneasy about this. Looking ahead, with filesystem
capabilities, one can simulate this same situation with a setuid
'non-root' program as follows:
[EMAIL PROTECTED] ~]$ cat > test.c
main()
{
printf("sleeping (%u)\n",
-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
].
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Signed-off-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> This patch takes advantage of the increase in capability bits
> to allocate capabilities for Mandatory Access
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Signed-off-by: Andrew G. Morgan [EMAIL PROTECTED]
Cheers
Andrew
Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
This patch takes advantage of the increase in capability bits
to allocate capabilities for Mandatory Access Control.
-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
].
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
I still feel a bit uneasy about this. Looking ahead, with filesystem
capabilities, one can simulate this same situation with a setuid
'non-root' program as follows:
[EMAIL PROTECTED] ~]$ cat test.c
main()
{
printf(sleeping (%u)\n,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
> diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
> linux-2.6.24-rc3-mm1-base/include/linux/capability.h
> linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
> ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
linux-2.6.24-rc3-mm1-base/include/linux/capability.h
linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I believe it was you who once eloquently observed that, at its heart,
the POSIX (sic) capabilities model was all about providing a mechanism
for overriding the prevailing security policy (be it MAC or DAC or
whatever) in a defined way.
Casey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
> In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
> I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
> CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
> unnecessarily ties
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
unnecessarily ties it to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I believe it was you who once eloquently observed that, at its heart,
the POSIX (sic) capabilities model was all about providing a mechanism
for overriding the prevailing security policy (be it MAC or DAC or
whatever) in a defined way.
Casey
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> The problem is that when you run a setuid binary, its pP and pE are
> fully raised. The following patch fixes it for me. Chris, does it fix
> your problem? Andrew, am I again confusing myself and doing something
> unsafe?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
The problem is that when you run a setuid binary, its pP and pE are
fully raised. The following patch fixes it for me. Chris, does it fix
your problem? Andrew, am I again confusing myself and doing something
unsafe?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> However, I got around the problem by making the code change manually -
> and my network connection is now working. Looking at the code being
> bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat
i] || pP.cap[i]) {
/* Cannot represent w/ legacy structure */
return -ERANGE;
Thanks
Andrew
Kevin Winchester wrote:
> On November 17, 2007 01:16:58 am Andrew Morgan wrote:
>> Hi,
>>
>> This warning is just saying that you might want to reco
]) {
/* Cannot represent w/ legacy structure */
return -ERANGE;
Thanks
Andrew
Kevin Winchester wrote:
On November 17, 2007 01:16:58 am Andrew Morgan wrote:
Hi,
This warning is just saying that you might want to reconsider
recompiling your dhclient with a newer libcap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
However, I got around the problem by making the code change manually -
and my network connection is now working. Looking at the code being
bypassed:
if (pE.cap[i] || pP.cap[i] || pP.cap[i])
looks somewhat weird as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This warning is just saying that you might want to reconsider
recompiling your dhclient with a newer libcap - which has native support
for 64-bit capabilities. This is supposed to be informative, and not be
associated with any particular error.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This warning is just saying that you might want to reconsider
recompiling your dhclient with a newer libcap - which has native support
for 64-bit capabilities. This is supposed to be informative, and not be
associated with any particular error.
ties.
>>
>>> But no IBM had to do it.
>> Err, no. It was done by Andrew Morgan back in the dark ages.
>> Why on earth do you think IBM did it?
>
> Posix file capabilities the option to replace SUID bit with something
> more security safe only handing out segments
, no. It was done by Andrew Morgan back in the dark ages.
Why on earth do you think IBM did it?
Posix file capabilities the option to replace SUID bit with something
more security safe only handing out segments of root power instead of
the complete box and dice like SUID. Even different on a user by user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([EMAIL PROTECTED]):
>> On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote:
[..]
>>> Also don't do file-capabilities signaling checks when uids for
>>> the processes don't match, since the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote:
[..]
Also don't do file-capabilities signaling checks when uids for
the processes don't match, since the standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[kernel/signal.c:check_kill_permission() could probably benefit from
getting more consistently indented!]
I'm not sure I can grok your comment. Did you mean:
/* as per, check_kill_permission(), permit if tasks have same uid */
As to content:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ackd.
Cheers
Andrew
Serge E. Hallyn wrote:
>>From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 11:22:04 -0500
> Subject: [PATCH 1/1] file capabilities: allow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ackd.
Cheers
Andrew
Serge E. Hallyn wrote:
From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 11:22:04 -0500
Subject: [PATCH 1/1] file capabilities: allow sigcont
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[kernel/signal.c:check_kill_permission() could probably benefit from
getting more consistently indented!]
I'm not sure I can grok your comment. Did you mean:
/* as per, check_kill_permission(), permit if tasks have same uid */
As to content:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting Chris Wright ([EMAIL PROTECTED]):
>> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
>>> I guess now that I've written this out, it seems pretty clear
>>> that capget64() and capget64() are the way to go. Any objections?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Quoting Chris Wright ([EMAIL PROTECTED]):
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
I guess now that I've written this out, it seems pretty clear
that capget64() and capget64() are the way to go. Any objections?
How is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Howells wrote:
> Move the effective capabilities mask from the task struct into the credentials
> record.
>
> Note that the effective capabilities mask in the cred struct shadows that in
> the task_struct because a thread can have its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Howells wrote:
Move the effective capabilities mask from the task struct into the credentials
record.
Note that the effective capabilities mask in the cred struct shadows that in
the task_struct because a thread can have its capabilities
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> To summarize more clearly, I think that so long as we support
> process trees with a sort of !SECURE_NOROOT support, that
> support should include the ability to use prctl(KEEP_CAPS) the
> way one uses it now.
> When a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
To summarize more clearly, I think that so long as we support
process trees with a sort of !SECURE_NOROOT support, that
support should include the ability to use prctl(KEEP_CAPS) the
way one uses it now.
When a process
ether with the changes
> Andrew has for securebits.
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFG08y0QheEq9QabfIRAnUhAKCEHyUko292kULNTkRqQOGki2NohgCdGXvV
bc+bHzBbI6sPimdf4UTAzGY=
=vB0u
-END PGP SIGNATURE-
>From a8366ab7a12ed4283e24096e891a
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFG08y0QheEq9QabfIRAnUhAKCEHyUko292kULNTkRqQOGki2NohgCdGXvV
bc+bHzBbI6sPimdf4UTAzGY=
=vB0u
-END PGP SIGNATURE-
From a8366ab7a12ed4283e24096e891ac13c1d471756 Mon Sep 17 00:00:00 2001
From: Andrew Morgan [EMAIL PROTECTED]
Date
his patch therefore removes it.
>
> Actually IIUC Andrew Morgan had plans of making securebits per-process,
> which would make them far more usable.
>
> Now maybe he'd just as soon start with a clean slate... Andrew?
-BEGIN PGP SIGNA
it.
Actually IIUC Andrew Morgan had plans of making securebits per-process,
which would make them far more usable.
Now maybe he'd just as soon start with a clean slate... Andrew?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux
fcaps on inode change (v2)
Signed-off-by: Andrew Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGuBZDQheEq9QabfIRAtoVAJ9uOG2q9Za0CJqmH0ueLgUHmRIABACdHW3c
SykZm/puZe5JPpiVPAF2rS8=
=Smnk
-END PGP SIGNATURE-
-
To unsub
)
Signed-off-by: Andrew Morgan [EMAIL PROTECTED]
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGuBZDQheEq9QabfIRAtoVAJ9uOG2q9Za0CJqmH0ueLgUHmRIABACdHW3c
SykZm/puZe5JPpiVPAF2rS8=
=Smnk
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fine with me.
Cheers
Andrew
Serge E. Hallyn wrote:
>>From 88115394044e697ac852f7fb9f30483e87f4f598 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 11 Jul 2007 10:01:01 -0400
> Subject: [PATCH 1/1] file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fine with me.
Cheers
Andrew
Serge E. Hallyn wrote:
From 88115394044e697ac852f7fb9f30483e87f4f598 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Wed, 11 Jul 2007 10:01:01 -0400
Subject: [PATCH 1/1] file capabilities: clear
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> 1. Exactly Andrew describes. Once userspace switches to a new cap
> format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
> 2. As Andrew describes, but also encode the version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
1. Exactly Andrew describes. Once userspace switches to a new cap
format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
2. As Andrew describes, but also encode the version number
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
>> Would there be a difference between that and setting either fI or fP
>> (depending on your intent) to those caps, and setting fE=1 in Andrew's
>> scheme?
>
> Arg, you're making me think. The POSIX group went through this,
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
kfree(dcaps);
> Move this two lines down (rc defaults to 0 in goto above):
> from here-->
+clear_caps:
+ if (rc) {
> to here-->
>
>> Hmm? But if we succeeded we still want to free dcaps if we
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
>> The only reason for having an fE bitmap is to allow a capability-aware
>> program (you really trust to do its privileged operations carefully) to
>> be lazy and get some of its capabilities raised for free. Perhaps you
>> can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>> Does that explain it?
>
> Yes, thanks, but then it still could come in handy to have fE be a full
> bitset, so the application gets some eff caps automatically, while
> others it has to manually set...
[We touched on this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This contains a typo:
Serge E. Hallyn wrote:
>>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 27 Jun 2007 19:55:27 -0400
> Subject: [PATCH 1/1] file capabilities:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This contains a typo:
Serge E. Hallyn wrote:
From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Wed, 27 Jun 2007 19:55:27 -0400
Subject: [PATCH 1/1] file capabilities: get_file_caps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Does that explain it?
Yes, thanks, but then it still could come in handy to have fE be a full
bitset, so the application gets some eff caps automatically, while
others it has to manually set...
[We touched on this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
The only reason for having an fE bitmap is to allow a capability-aware
program (you really trust to do its privileged operations carefully) to
be lazy and get some of its capabilities raised for free. Perhaps you
can clarify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
kfree(dcaps);
Move this two lines down (rc defaults to 0 in goto above):
from here--
+clear_caps:
+ if (rc) {
to here--
Hmm? But if we succeeded we still want to free dcaps if we
kmalloc()'d it.
I wasn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
Would there be a difference between that and setting either fI or fP
(depending on your intent) to those caps, and setting fE=1 in Andrew's
scheme?
Arg, you're making me think. The POSIX group went through this,
let me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>
>> I don't particularly mind, but can you point out any case where
>> it is an advantage to have the one bit for f'E rather than just
>> drop f'E altogether? Instead of having
>
>> f'I=something
>> f'P=something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I don't particularly mind, but can you point out any case where
it is an advantage to have the one bit for f'E rather than just
drop f'E altogether? Instead of having
f'I=something
f'P=something
f'E=off
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should
78 matches
Mail list logo
