if (rc < 0) {
+ 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
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
ability code 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:
>> An
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
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(), j
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
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, it is not
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
longs is on 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 ca
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:
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
+if (!!cap_issubset(*inheritable,
+ cap_combine(target->cap_inherita
OK, I got understood the intention 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
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
y more 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 unsubscri
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
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
^Cap
CapInh:
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]>
**
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(+),
rcu_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-in
common bitops.
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
>
return 0;
+ } 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 unsu
fective;
bprm->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 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/
tc('\n', stderr);
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
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 envir
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 me
nk to implement the
> accounting at userspace, so this piece of 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 do
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
dify the kernel-tree".
But, any 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 Promot
ne
process-aggregation with one process.
# /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 b
king a collection of accounting information should be merged
>> into BSD-accounting and implemented 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
rocess-aggregation is necessary.
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
33 matches
Mail list logo
