if (rc < 0) {
+ posix_acl_release(clone);
return rc;
+ }
if (rc > 0)
jffs2_iset_acl(inode, >i_acl_access, clone);
Indeed, there was a possibility to cause memory leaking.
Acked-by: KaiGai Koh
) {
+ posix_acl_release(clone);
return rc;
+ }
if (rc 0)
jffs2_iset_acl(inode, f-i_acl_access, clone);
Indeed, there was a possibility to cause memory leaking.
Acked-by: KaiGai Kohei [EMAIL PROTECTED]
--
OSS Platform
James Morris wrote:
> On Wed, 2 Jan 2008, KaiGai Kohei wrote:
>
>>> Another issue is that securityfs depends on CONFIG_SECURITY, which might be
>>> undesirable, given that capabilities are a standard feature.
>> We can implement this feature on another pseudo fil
de like CAP_MAC_ADMIN.
However, when we implement a program which can deal with arbitrary
capabilities, it should obtain codes of them dynamically, because
it enables to work itself on the feature kernel.
Thanks,
> Cheers
>
> Andrew
>
> KaiGai Kohei wrote:
>> Andrew Morga
, when we implement a program which can deal with arbitrary
capabilities, it should obtain codes of them dynamically, because
it enables to work itself on the feature kernel.
Thanks,
Cheers
Andrew
KaiGai Kohei wrote:
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai
James Morris wrote:
On Wed, 2 Jan 2008, KaiGai Kohei wrote:
Another issue is that securityfs depends on CONFIG_SECURITY, which might be
undesirable, given that capabilities are a standard feature.
We can implement this feature on another pseudo filesystems.
Do you think what filesystem
Andrew Morgan wrote:
> -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 e
James Morris wrote:
On Fri, 28 Dec 2007, 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)
Why can't early userspace itself mount
James Morris wrote:
On Fri, 28 Dec 2007, 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)
Why can't early userspace itself mount
Andrew Morgan wrote:
-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
James Morris wrote:
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
+ snprintf(tmp, sizeof(tmp),
+cap_entry == _entries[0] ? "0x%08x" : "%u",
+cap_entry->code);
+ len = strlen(tmp);
You don't need to call strlen(), just u
apability.h
>> 3. added to this list...
>>
>> Could you integrate the two lists (not sure how offhand), or at least
>> put them in the same place?
kernel/cap_names.sh generates the body of cap_entries[] array,
and it is invoked when we make the kernel.
Signed-off-by: KaiGai Kohei &l
Serge E. Hallyn wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.
In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However
Serge E. Hallyn wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.
In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However
CAP_LAST_CAP in capability.h
3. added to this list...
Could you integrate the two lists (not sure how offhand), or at least
put them in the same place?
kernel/cap_names.sh generates the body of cap_entries[] array,
and it is invoked when we make the kernel.
Signed-off-by: KaiGai Kohei [EMAIL
James Morris wrote:
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
+ snprintf(tmp, sizeof(tmp),
+cap_entry == cap_entries[0] ? 0x%08x : %u,
+cap_entry-code);
+ len = strlen(tmp);
You don't need to call strlen(), just use scnprintf() and grab the return
cap_ipc_ownercap_setgidcap_sys_ptrace
# cat cap_audit_write ; echo
29
# cat cap_sys_chroot ; echo
18
# cat version ; echo
0x19980330
# cat index; echo
31
#
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
Signed-off-by: KaiGai Kohei <[EMAIL
cap_ipc_ownercap_setgidcap_sys_ptrace
# cat cap_audit_write ; echo
29
# cat cap_sys_chroot ; echo
18
# cat version ; echo
0x19980330
# cat index; echo
31
#
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
Signed-off-by: KaiGai Kohei [EMAIL PROTECTED
n several lines, all configurations
> are simplly compounded.
>
> In the above example, if tak belongs to webadm and users group,
> he will get cap_sys_pacct and cap_net_bind_service pI, and lost
> cap_sys_chroot and cap_sys_module from his cap_bset.
&g
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
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
cap_sys_pacct and cap_net_bind_service pI, and lost
cap_sys_chroot and cap_sys_module from his cap_bset.
Thanks,
Signed-off-by: KaiGai Kohei [EMAIL PROTECTED]
--
pam_cap/capability.conf |6 +
pam_cap/pam_cap.c | 495 ---
2 files changed, 305
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_inherita
of the condition.
It seems to me reasonable policy.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
This patch fixes incorrect condition added by per-process capability
bounding set patch.
It intends to limit no new pI capabilities outside bounding set.
Signed-off-by:
of the condition.
It seems to me reasonable policy.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
This patch fixes incorrect condition added by per-process capability
bounding set patch.
It intends to limit no new pI capabilities outside bounding set.
Signed-off-by: KaiGai
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
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
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
e than bounding set, at least.
What is the purpose of this checking?
In the initial state, any process have no inheritable capability set
and full bounding set. Thus, we cannot do capset() always.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe fr
set, at least.
What is the purpose of this checking?
In the initial state, any process have no inheritable capability set
and full bounding set. Thus, we cannot do capset() always.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei [EMAIL PROTECTED]
--
To unsubscribe from this list
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
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
b:-cap_dac_override kaigai
# It drops only cap_sys_admin from b-set of any user within users group.
b:-cap_sys_admingroup:users
Thanks,
Cheers
Andrew
[EMAIL PROTECTED] wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
The capability bounding set is a set beyon
for
informational purpose (like ulimit, umask).
However, using any other separate config file is conservative
and better. One candidate is "/etc/security/capability.conf"
defined as the config file of pam_cap.
Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>
--
To unsubscribe from this lis
for
informational purpose (like ulimit, umask).
However, using any other separate config file is conservative
and better. One candidate is /etc/security/capability.conf
defined as the config file of pam_cap.
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe
# It drops only cap_sys_admin from b-set of any user within users group.
b:-cap_sys_admingroup:users
Thanks,
Cheers
Andrew
[EMAIL PROTECTED] wrote:
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
The capability bounding set is a set beyond which capabilities
000
CapPrm: dffe
CapEff: dffe
[EMAIL PROTECTED] tak]#
# BTW, I replaced the James's address in the Cc: list,
# because MTA does not accept it.
--
KaiGai Kohei <[EMAIL PROTECTED]>
**
: dffe
CapEff: dffe
[EMAIL PROTECTED] tak]#
# BTW, I replaced the James's address in the Cc: list,
# because MTA does not accept it.
--
KaiGai Kohei [EMAIL PROTECTED]
pam_cap_drop.c
Adrian Bunk wrote:
jffs2_get_acl() can now become static again.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: KaiGai Kohei <[EMAIL PROTECTED]>
---
fs/jffs2/acl.c |2 +-
fs/jffs2/acl.h |2 --
2 files changed, 1 insertion(+),
Adrian Bunk wrote:
jffs2_get_acl() can now become static again.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: KaiGai Kohei [EMAIL PROTECTED]
---
fs/jffs2/acl.c |2 +-
fs/jffs2/acl.h |2 --
2 files changed, 1 insertion(+), 3 deletions
read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
--
KaiGai Kohei <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info
();
list_for_each_entry(...) {
}
rcu_read_unlock();
--
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
.
Any comment please.
Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:37 +0900, KaiGai Kohei wrote:
>> Paul Moore wrote:
>>> On Tuesday, September 11 2007 11:08:44 pm KaiGai Kohei wrote:
>>>> The attached patch applies the standard bitmap operations
>>>>
comment please.
Stephen Smalley wrote:
On Thu, 2007-09-13 at 10:37 +0900, KaiGai Kohei wrote:
Paul Moore wrote:
On Tuesday, September 11 2007 11:08:44 pm KaiGai Kohei wrote:
The attached patch applies the standard bitmap operations
for the iteration macro of ebitmap, and enables to improve
} else if (!strncmp(name, XATTR_SECURITY_PREFIX,
sizeof(XATTR_SECURITY_PREFIX) - 1) &&
!capable(CAP_SYS_ADMIN))
return -EPERM;
--
Open Source Software Promotion Center, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
-
To unsubscribe from
,
sizeof(XATTR_SECURITY_PREFIX) - 1)
!capable(CAP_SYS_ADMIN))
return -EPERM;
--
Open Source Software Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
return err;
+ rc = cap_from_disk(dcaps, , rc);
+ if (rc)
+ goto out_free;
+ rc = check_cap_sanity();
+ if (rc)
+ goto out_free;
bprm->cap_effective = caps.effective;
bprm->cap_permitted = caps.permitted;
bprm->cap_
-cap_permitted = caps.permitted;
bprm-cap_inheritable = caps.inheritable;
- return 0;
+out_free:
+ kfree(dcaps);
+out:
+ dput(dentry);
+ return rc;
}
#else
static inline int set_file_caps(struct linux_binprm *bprm)
--
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from
tderr);
exit(0);
}
[EMAIL PROTECTED] libcap-1.10.kg]$
Because '__CAP_BITS' is decided at compiling time, I think it's not
appropriate to indicate the length of _cap_names[] which is linked
at run time.
Therefore, I add a new integer variable _cap_names_num to represent
the length of _cap_nam
?FrontPage#b556e50d
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hello, Guillaume
I tried to measure the process-creation/destruction performance on
2.6.11-rc4-mm1 plus
some extensiton(Normal/with PAGG/with Fork-Connector).
But I received a following messages endlessly on system console with
Fork-Connector extensiton.
# on IA-64
Hello, Guillaume
I tried to measure the process-creation/destruction performance on
2.6.11-rc4-mm1 plus
some extensiton(Normal/with PAGG/with Fork-Connector).
But I received a following messages endlessly on system console with
Fork-Connector extensiton.
# on IA-64
Hello,
> I tested without user space listeners and the cost is negligible. I will
> test with a user space listeners and see the results. I'm going to run
> the test this week after improving the mechanism that switch on/off the
> sending of the message.
I'm also trying to
Hello,
I tested without user space listeners and the cost is negligible. I will
test with a user space listeners and see the results. I'm going to run
the test this week after improving the mechanism that switch on/off the
sending of the message.
I'm also trying to
code is out of the game, no?
Indeed, I'm not opposed to implement the accounting in userspace and
using netlink-socket for kernel-daemon communication. But definition
of process-grouping based on any grouping policy should be done
in kernel space at reasonability viewpoint.
Thanks.
--
Linux Promotion Cent
Hi,
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality can
implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same
Hi,
Kaigai Kohei [EMAIL PROTECTED] wrote:
In my understanding, what Andrew Morton said is If target functionality can
implement in user space only, then we should not modify the kernel-tree.
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same common machinery
Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y kind of kernel support was required to handle process lifecycle events
for the accounting per process-aggregation and so on, from our discussion.
I'm also opposed to an adhoc approach, like CSA depending on ELSA.
We should walk hight road.
Thanks,
--
Linux Promotion Center, NEC
KaiGai Kohei <[EMAIL
for the accounting per process-aggregation and so on, from our discussion.
I'm also opposed to an adhoc approach, like CSA depending on ELSA.
We should walk hight road.
Thanks,
--
Linux Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
ss.
# /proc//loginuid might be candidate, but it's out of original purpose.
We might be able to make alike system, but is it hard to implement strict
process-aggregation without any kernel supports?
I think that well thought out kernel-modification is better than ad-hoc
implementation on user-spac
.
We might be able to make alike system, but is it hard to implement strict
process-aggregation without any kernel supports?
I think that well thought out kernel-modification is better than ad-hoc
implementation on user-space.
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED
ented as a part of monolithic kernel
>> as Guillaume said.
>
>
> This sounds good. I am interested in learning how ELSA saves off
> the per-process accounting data before the data got disposed. If
> that scheme works for CSA, we would be very happy to adopt the
> sche
and it provides no way to handle process-aggregation.
Thanks,
- jay
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
essary.
And, making a collection of accounting information should be merged
into BSD-accounting and implemented as a part of monolithic kernel
as Guillaume said.
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsub
and implemented as a part of monolithic kernel
as Guillaume said.
Thanks.
--
Linux Promotion Center, NEC
KaiGai Kohei [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
66 matches
Mail list logo
