Hello.
I've just returned from ELC2007 and
I haven't read all posts in this thread yet,
but I want to comment to this function.
In AppArmor, we are interested in pathnames relative to the namespace root.
This is the same as d_path() except for the root where the search ends. Add
a function
Cong WANG wrote:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.2.tar.bz2
isn't it what you want?
It's currently 404 (Not Found) error.
http://www2.kernel.org/ page is still showing 2.6.20.1
although it once showed 2.6.20.2 .
-
To unsubscribe from this list: send the line unsubscribe
Hello!
TOMOYO Linux is an access control enhancement patch
utilizing struct task_struct.
http://tomoyo.sourceforge.jp/
It supports 2.4.30 and later/2.6.11 and later vanilla kernels
and some of distributor's kernels.
Kickstarting page for CentOS 4.4, Fedora Core 6,
Debian Sarge, and Ubuntu 6.10
Hello.
[EMAIL PROTECTED] wrote:
Ouch. The .c files should generally be built into their own .o files and
then the Makefile should do something like
obj-$(CONFIG_SYAORAN) += syaoran.o
unless there's *really* good reasons for including .c files (such as an
otherwise-messy
Hello.
Indan Zupancic wrote:
I want to use this filesystem in case where a process with root privilege
was
hijacked but the behavior of the hijacked process is still restricted by
MAC.
1) If the behaviour can be controlled, why can't the process be
disallowed to change anything
Hello.
Christoph Hellwig wrote:
Just FYI: A NACK to such an addition doesn't simply go away by
ignoring it.
Excuse me. What NACK is remaining?
About the below comments?
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack
Exactly.
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hello.
[EMAIL PROTECTED] wrote:
Good summary - probably should add that to the patch, drop it into
Documentation/syaoran-config.txt or similar...
I see.
Modification while reading *is* an issue, but can probably be worked around
with some clever locking. The race condition I was thinking of
Hello.
Brent Casavant wrote:
However, the program would occasionally get into a situation where
a call to recv(sockfd, buf, len, MSG_PEEK) returns some number
of bytes less than the requested length, and persists in this state
(i.e. retrying the call continues to return the same amount of
Hello.
Indan Zupancic wrote:
Good point, but I assume they all have at least a directory granularity, and
then
/dev/ can be static and udev and other can have free reign in e.g.
/dev/dynamic/.
Just use subdirs for the dynamic stuff and this granularity problem is, with
slight
Hello.
Indan Zupancic wrote:
It seems to me that the alternatives you are proposing include
modification of userland applications. But my assumption is
that Don't require modification of userland applications.
If you want a secure system it isn't that unreasonable to expect
Hello.
Indan Zupancic wrote:
That only the tiny daemon can modify /dev/ is done with MAC rules,
the ones that should be the default for all applications except udev by
default already. For teh kernel nothing changes.
OK. You assume use of MAC with enough fine grained access control.
Hello.
James Morris wrote:
TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration.
Why aren't you using securityfs for this? (It was designed for LSMs).
Doh, it is using securityfs, don't worry.
I got a mm-commits mail titled
+
Hello.
Greg KH wrote:
If sysfs becomes not available at /sys/ , where securityfs is going to be
mounted?
sysfs is not going away any time soon, don't worry :)
I see. Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Hello.
I checked my patch using checkpatch.pl version 0.10
and I got the following error.
ERROR: need consistent spacing around '*' (ctx:WxV)
#2334: FILE: security/tomoyo/common.c:2306:
+static unsigned int tmy_poll(struct file *file, poll_table *wait)
Hello.
Satyam Sharma wrote:
Looks like a checkpatch.pl bug to me -- that was nothing to warn about.
I see. I'll wait for next version.
struct poll_table {
poll_queue_proc qproc;
};
poll_table is defined in include/linux/poll.h .
To change this, we have to do sed -i
Hello.
Eric W. Biederman wrote:
name[CTL_MAXNAME} is not valid.
name[0...CTL_MAXNAME-1] is valid.
Yes.
The check that got lost in the refactoring was specfically:
- if (tmp.nlen = 0 || tmp.nlen = CTL_MAXNAME)
- return -ENOTDIR;
Thus I think tmp.nlen == CTL_MAXNAME
Andrew, please replace previous patch with this one.
This one returns -ENOTDIR.
--
Original patch forgot to check args-nlen.
I don't know why args-nlen == CTL_MAXNAME is rejected,
but it has been rejected traditionally.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
Cc: Eric W. Biederman
Hello.
Andrew Morton wrote:
I believe (args-nlen CTL_MAXNAME) was correct.
I'll leave it to you.
But if you want to allow args-nlen == CTL_MAXNAME,
you also need to update do_sysctl().
int do_sysctl(int __user *name, int nlen, void __user *oldval, size_t __user
*oldlenp,
void
Hello.
Trond Myklebust wrote:
This patch allows LSM hooks refer previously associated struct vfsmount
parameter
so that they can calculate pathname of given struct dentry.
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack (unless
YOSHIFUJI Hideaki wrote:
I think you can use in6_pton() here.
in4_pton().
I see. I'll try it later.
Thanks.
-
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
Hello.
Thank you for your feedback.
Paul Moore wrote:
With this patch the 'cpu_flags' variable will be used in two different
if-blocks in this function and declared locally within each block. Please
move the 'cpu_flags' declaration to the top of the function so it only needs
to be
Hello.
Trond Myklebust wrote:
The problem is that you have thrown away the main tool for documenting
the requirement, and for enforcing correctness (i.e. function argument
checking by the compiler).
I'm sorry. I wanted to know whether the below approach is possible.
The old functions are
Hello.
Trond Myklebust wrote:
I'm confused. How do you tell the difference between a 'userland'
request and a 'kernel' request, and why is the latter safe from a
security perspective?
For example, if userland process wants to create a directory,
it will call mkdir(2).
In the kernel, mkdir(2)
]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
include/linux/security.h | 74 +++
kernel/signal.c | 17 ++
net/core/datagram.c | 29 --
net/socket.c |7 +++-
security/dummy.c | 32
Hello.
Christoph Hellwig wrote:
NACK to this. Passing function parameters through the task_struct is
definitely not an acceptable hack
Exactly. Having a vfsmount other than the current processes root or
current working directory in task_struct doesn't make any sense.
The process's root and
Hello.
Paul Moore wrote:
If that is the case then the second call to
skb_peek() will return a different skb then the one you passed to
security_post_recv_datagram().
Yes. The second call to skb_peek() might return a different skb than the one
I passed to security_post_recv_datagram().
Hello.
Indan Zupancic wrote:
What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Mandatory access control (MAC) prevents them from mounting tmpfs on top of /dev
.
MAC mediates namespace manipulation requests such as mount()/umount().
Also, if they have root there are
Hello.
Indan Zupancic wrote:
If MAC can avoid all that, then why can't it also avoid tampering with /dev?
If MAC implementation handles filename and its attributes pair, this filesystem
is not needed.
But I don't know MAC implementations that handle this pair.
SELinux's granularity is allow
Hello.
Al Boldi wrote:
I think the answer is obvious: Tetsuo wants to add functionality that the
MACs are missing. So, instead of adding this functionality per MAC, he
proposes to add it as ground work, to be combined with any MAC.
Yes, that's right.
This filesystem is designed to be used
( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)
Hello.
David Wagner wrote:
But the point is that it's not enough just to prevent attackers
from mounting other filesystems over this filesystem. I can think
of all sorts of ways that an admin-level attacker might be able to
prevent
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2).
To use your approach, i guess we would have to use selinux (or tomoyo)
Hello.
Serge E. Hallyn wrote:
But your requirements are to ensure that an application accessing a
device at a well-known location get what it expect.
Yes. That's the purpose of this filesystem.
So then the main quesiton is still the one I think Al had asked - what
keeps a rogue
Hello.
Serge E. Hallyn wrote:
Nope, try
touch /root/hda1
ls -l /root/hda1
mount --bind /dev/hda1 /root/hda1
ls -l /root/hda1
[EMAIL PROTECTED] ~]# touch /root/hda1
[EMAIL PROTECTED] ~]# ls -l /root/hda1
-rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1
[EMAIL PROTECTED] ~]# mount
Hello.
Radoslaw Szkodzinski (AstralStorm) wrote:
Actually, who needs to create device nodes? Just prohibit everyone from
creating them, except installer and udev personality.
This means removing CAP_MKNOD on a global scale.
What happens if the root tampers udev's configuration file?
The udev
Hello.
I encountered a BUG().
I didn't encounter this bug for 2.6.24-rc5-mm1 .
I guess this bug was introduced between 2.6.24-rc5-mm1 and 2.6.24-rc6-mm1 .
I placed .config at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-rc6-mm1
The dmesg is attached below.
Regards.
-
Linux version
).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/ramfs/inode.c | 101 -
fs/ramfs/syaoran.h | 1066
Hello.
Ingo Molnar wrote:
does the patch below help?
Yes, it solved this bug.
Thank you.
--
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
mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
mm/slab.c |1 +
mm/slob.c |1 +
2 files changed, 2 insertions(+)
--- linux-2.6-mm.orig/mm/slab.c
+++ linux-2.6-mm/mm/slab.c
@@ -4479,3 +4479,4 @@ size_t
Hello.
I can't pass memory allocated by kmalloc() to ksize()
if it is allocated by SLUB allocator and
size is larger than (I guess) PAGE_SIZE / 2.
Regards.
-- Kernel config (grep CONFIG_SLUB .config) --
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
# CONFIG_SLUB_DEBUG_ON is not set
Hello.
Adrian Bunk wrote:
mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know
why.
That's due to the fact that my patch to remove this unused export from
slub was not yet applied...
So, removing exports is intended thing?
Where is the modular in-kernel user?
I
Hello.
Vegard Nossum wrote:
That didn't work. I guess that's what you get for no testing ;-) After
some more investigations, it seems that this is the correct way to fix
it (and tested!):
It worked in my environment too.
Please apply to 2.6.24-rc3-git6's tree.
Thank you.
--
To unsubscribe
Hello.
Arnaldo Carvalho de Melo wrote:
But I think ksize() should be available to kernel modules as well as
kmalloc() etc.
Why do you think so? You have to justify that with some valid use.
Is there an alternative function?
If not, it sounds to me that this is a regression.
We couldn't know
Hello.
I posted a message to [EMAIL PROTECTED],
[EMAIL PROTECTED] and [EMAIL PROTECTED]
11 hours ago, but it seems to me my message has not delivered yet.
Usually it won't take 10 minutes to be delivered.
So, I'm thinking my messages was dropped.
Does vger.kernel.org have spam filter and
Hello.
Matti Aarnio wrote:
Does vger.kernel.org have spam filter and automatically drop spams?
Yes. Yes. And even worse: SILENTLY drop it. The reason was:
global taboo header: m!OJFS!
I don't recall why that was declared taboo, but it apparently bites
on References: headers..
Hello.
Paul Moore wrote:
My apologies, I mistakenly read the following if statement in your patch:
+ if (skb == skb_peek(sk-sk_receive_queue)) {
+ __skb_unlink(skb, sk-sk_receive_queue);
+ atomic_dec(skb-users);
+ }
I read the conditional as
this datagram
will repeat recvmsg() forever, which is a worse side effect.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
include/linux/security.h | 34 +-
net/core/datagram.c | 26 --
net
Hello.
I found that
CONFIG_BLK_DEV_RAM=m
in my .config makes
#ifdef CONFIG_BLK_DEV_RAM
false.
I guess something is wrong with .config parsing.
Regards.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
Hello.
Randy Dunlap [EMAIL PROTECTED] wrote:
I don't think that this is a change from the recent past.
Oh, it is my mistake.
I found that choosing CONFIG_BLK_DEV_RAM=m makes
impossible to pass an initrd image since
populate_rootfs() in init/initramfs.c omits
code for checking whether the image
Hello.
I have proposed this filesystem a few years ago.
Once again, I'm proposing this filesystem toward inclusion into mainline.
I'll update for -mm tree if this filesystem is likely acceptable.
Regards.
(This is a resent message of [00/02] since it seems to be dropped.)
--
To unsubscribe from
SELinux doesn't guarantee filename and its attribute.
The purpose of this filesystem is to ensure filename and its attribute
(e.g. /dev/null is guaranteed to be a character device file
with major=1 and minor=3).
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/syaoran/syaoran.c | 338
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 21 +
fs/Makefile |1 +
2 files changed, 22 insertions(+)
--- linux-2.6.24-rc5.orig/fs/Kconfig
+++ linux-2.6.24-rc5/fs/Kconfig
@@ -1555,6 +1555,27 @@ config UFS_DEBUG
Y here. This will result
Hello.
David Newall wrote:
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) This goes
against
Hello.
I meant that /dev must be mounted for read-write mode
Again, why?
You can mount / partition for read-only mode if you wish to do so.
But you cannot make /dev directory for read-only.
You won't be able to login to the system because /sbin/mingetty
fails to chown/chmod /dev/tty* if
Hello.
David Newall wrote:
You won't be able to login to the system because /sbin/mingetty
fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode.
Good point. So, if only root can modify files in /dev, what's the
problem you're fixing? (I'm sure you tried to explain this
But use of this filesystem is still valid when this filesystem is used with
policy based mandatory access control (such as SELinux, TOMOYO Linux)
because this filesystem guarantees where policy based mandatory access control
can't guarantee (i.e. filename and its attribute).
Policy based
Hello.
Serge E. Hallyn wrote:
I apologize if I'm commiting a faux pas by asking this, but any chance
of renaming this to something like strictdev or sdev, or at least with
'dev' in it somewhere?
You are not commiting a faux pas. But, this naming is my personal feeling. ;-)
You can see the
proceed to other administrator's subtrees.
And more...
Your imagination invents new usage.
Authors:
Tetsuo Handa [EMAIL PROTECTED]
Toshiharu Harada [EMAIL PROTECTED]
Kentaro Takeda [EMAIL PROTECTED]
Appendix 1 - Usability features of TOMOYO Linux
TOMOYO Linux switches the context
Hello.
Thank you for feedback.
Serge E. Hallyn wrote:
TOMOYO Linux is a DIY tool for understanding and protecting your system.
TOMOYO Linux policy definitions are absolutely readable to Linux users, and
TOMOYO Linux supports unique policy learning mechanism which automatically
Are they
Hello.
Serge E. Hallyn wrote:
Auto-learning in itself doesn't seem novel, but so you're saying it's
novel in ust how integrated it is - no mnual intervention necessary?
You can run your system with only policy collected by learning mode.
Thus, you basically don't need manual intervention.
But
Hello.
Serge E. Hallyn wrote:
* namespace manipulation. (i.e. mount()/umount()/pivot_root())
do you track mounts namespace cloning?
Yes. TOMOYO can recognize mount operation with the following flags.
--bind --move --remount
--make-unbindable --make-private
Hello.
[EMAIL PROTECTED] wrote:
Please make a *big* notation someplace that learning mode is quite likely to
*not* produce a totally correct policy. In particular, it won't build rules
for
infrequently used code paths (such as error handling) unless you find a way to
exercise those paths
Hello.
Serge E. Hallyn wrote:
Does a process get different mount trees by just calling clone() or
unshare()?
My understanding is that clone() or unshare() disables propergation of
mount tree changes when somebody calls mount() or umount() or pivot_root().
Yes, with further propagation
Hello.
Thank you for reviewing.
Serge E. Hallyn wrote:
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
To integrate this nicer into tmpfs, at least
; touch /dev/null ).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 18 +
fs/ramfs
Hello.
Willy Tarreau wrote:
Your patch is very confusing. In your description, as well as in the
comments you talk about tmpfs, but your patch does not touch even one
line of tmpfs and only changes ramfs. Even your variables and arguments
refer to tmpfs. The Kconfig entry indicates that the
.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 18 +
include/linux/shmem_fs.h |5
mm/shmem.c | 124 +++
mm/shmem_mac.h | 57 +
mm/shmem_mac_debug.c | 183 +
mm/shmem_mac_init.c | 486
Hello.
Arjan van de Ven wrote:
when will you post this filesystem for inclusion into kernel.org kernel?
(and please really consider posting the patch together with that patch)
(also, if you can give a pointer to the source code of this filesystem
you might even get early code review)
I have
Hello.
Simon Arlott wrote:
I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then capability as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.
I think there are two other problems regarding LSM.
I think __set_page_dirty_no_writeback should be exported so that
tmpfs-like filesystems can use it.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
mm/page-writeback.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/mm/page-writeback.c
Hello.
Arjan van de Ven wrote:
I think __set_page_dirty_no_writeback should be exported so that
tmpfs-like filesystems can use it.
which filesystem is ACTUALLY using it?
Please submit the export together with the actual user; we have too
many unused exports already; the only way to
://www.mavetju.org/mail/view_thread.php?list=freebsd-archid=915145thread=yes
(Thank Yaakov for the pointers!)
So, switch to using TAILQ instead, which are more portable.
Reported-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Reported-by: Benjamin Poirier bpoir...@suse.de
Signed-off-by: Yann
Michal Marek wrote:
On 19.10.2012 14:10, Tetsuo Handa wrote:
Yann E. MORIN wrote:
So, switch to using TAILQ instead, which are more portable.
[...]
Excuse me, but your patch does not solve my problem because kconfig started
using macros which does not exist in @(#)queue.h 8.3 (Berkeley
Yann E. MORIN wrote:
Benjamin, All,
On Saturday 20 October 2012 Benjamin Poirier wrote:
From: Benjamin Poirier bpoir...@suse.de
sys/queue.h and CIRCLEQ in particular have proven to cause portability
problems (reported on Debian Sarge, Cygwin and FreeBSD)
Reported-by: Tetsuo Handa
P J P wrote:
Hello Kees,
+-- On Wed, 24 Oct 2012, Kees Cook wrote --+
| What should the code here _actually_ be doing? The _script and _misc
| handlers expect to rewrite the bprm contents and recurse, but the module
| loader want to try again. It's not clear to me what the binfmt
From af0876644f04eca9d59c96320447abb0af526079 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Date: Tue, 16 Oct 2012 22:30:38 +0900
Subject: [PATCH 3.7-rc1] Fix kconfig failure on old environments.
Commit 95ac9b3b menuconfig: Assign jump keys per-page instead
Hello.
Thank you for your comment.
James Morris wrote:
Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
struct something {
struct something *next;
void
Hello.
James Morris wrote:
Why do you need racy unlocked versions, in addition to the existing
security_task_kill() hook which is called safely via
check_kill_permission() ?
TOMOYO Linux provides delayed enforcing mode which allows administrator
judge interactively for requests that
Hello.
Thank you for your comment.
James Morris wrote:
I'm guessing you need this to determine the receiving process, rather than
the socket (which is available via security_sock_rcv_skb()).
Use of security_sock_rcv_skb() was discussed at
http://lkml.org/lkml/2007/8/28/74 ,
and answer is at
Hello.
James Morris wrote:
Would you please explain why you need another level of memory allocation?
What does it do apart from let you check for memory leaks?
Difference between tmy_alloc() and kmalloc() are
tmy_alloc() allows administrator know how much memory is used by TOMOYO
Linux
Hello.
YOSHIFUJI Hideaki wrote:
Introducing your own list is not good.
Please use hlist or introduce new slist.
James Morris wrote:
You're introducing a custom API, which is open-coded repeatedly throughout
your module.
All linked lists (at least, new ones) must use the standard kernel
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr-next is initialized with NULL.
(2) Later, ptr-next is assigned non-NULL address.
(3) Assigning to ptr-next is done atomically.
(4) wmb after asigning
Hello.
KaiGai Kohei wrote:
If so, you can apply RCU instead to avoid read lock
when scanning the list, like:
rcu_read_lock();
list_for_each_entry(...) {
}
rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes
Peter Zijlstra wrote:
Also, how do you avoid referencing dead data with your sll? I haven't
actually looked at your patches, but the simple scheme you outlined
didn't handle the iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list. It's
Hello.
YOSHIFUJI Hideaki wrote:
It is not a good practice. Please free such objects.
BTW, how many objects do you have in the list?
It varies from 0 to some thousands,
depending on the policy supplied by the administrator and/or the policy
appended by learning mode.
Peter Zijlstra wrote:
About use of singly-linked list:
What my SLL (singly-linked list) holds is bit different from other lists.
Almost all lists hold list of elements (e.g. buffer) that are used
*temporarily*.
Thus, adding to the list and removing from the list are essential.
My SLL holds ACL (access control
Hello.
Peter Zijlstra wrote:
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't
sleep.
You can indeed not sleep in an rcu_read_lock() section. However, you
could grab a reference on an item, stop the
Hello.
Thank you for pointing out.
Jun WANG wrote:
rcu_read_lock();
list_for_each_rcu(p, ...) {
ptr = list_entry(p, struct ..., list);
/* Grab a reference to ptr. */
rcu_read_unlock();
my_task_that_may_sleep(ptr);
rcu_read_lock();
/* Drop a reference to ptr. */
}
Hello.
Jun WANG wrote:
I'm sorry,I think I got your idea, if you do not need ptr in
my_task_that_may_sleep(), why you need to grab a reference to ptr. If
your my_task_that_may_sleep() needs ptr, and according to the
memory region pointed by ptr never be removed. you say,
it is ok to use ptr
Hello.
Peter Zijlstra wrote:
So, I don't need to grab a reference to ptr
because memory region pointed by ptr will never be kfree()ed.
And it is legal to use ptr after rcu_read_unlock()
because memory region pointed by ptr will never be kfree()ed.
Still think that is a very BAD (tm)
Hello.
Paul Moore wrote:
I apologize for not recognizing your approach from our earlier discussion on
the LSM mailing list in July. Unfortunately, I have the same objections to
these changes that I did back then and from what I can recall of the
discussion the rest of the kernel
Hello.
Thank you for your comment.
Hmm, I can't understand why I have to perform access control at enqueue time.
What I want to do is
allow process1 receive UDP packets from 10.0.0.1 port 1024
allow process2 receive UDP packets from 10.0.0.2 port 2048
when there is no guarantee that
Alexey Dobriyan wrote:
On Fri, Jul 20, 2007 at 12:37:45PM +0900, Tetsuo Handa wrote:
--- linux-2.6.22-orig/kernel/sysctl.c
+++ linux-2.6.22/kernel/sysctl.c
@@ -1190,9 +1190,9 @@
return -ENOTDIR;
if (get_user(n, name))
return -EFAULT;
+ if (!n
Hello.
Pavel Machek wrote:
What is that? Language parser in kernel?
Yes. This is a policy parser in kernel.
TOMOYO Linux' policy is passed from/to the kernel as a plain text
(i.e. ASCII printable) file via /proc/tomoyo interface.
For example, to add a permission to allow /usr/sbin/sshd
to
Hello.
Paul Moore wrote:
* post_recv_datagram is added in skb_recv_datagram.
Can you explain to me why this is not possible using the existing
security_socket_sock_rcv_skb() LSM hook?
socket_sock_rcv_skb() is a hook for enqueue time.
I want a hook for dequeue time, because what TOMOYO
Hello.
Kyle Moffett wrote:
This is probably not acceptable; I doubt there's a chance in hell
that TOMOYO will get merged as long as it has text-based-language
parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and
$PATH_BASED_LSM_ISSUES. See the long flamewars on AppArmor for
TOMOYO Linux is our work in the field of security enhanced Linux.
This is the fourth submission of TOMOYO Linux
( http://lkml.org/lkml/2007/10/2/170 ).
Thank you very much for feedbacks on previous submission.
We followed the following comments and now submitting again.
* Replace struct
TOMOYO Linux uses pathnames for auditing and controlling file access.
Therefore, namespace_sem is needed.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig
Data structures and prototype defitions for TOMOYO Linux.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
security/tomoyo/include/realpath.h | 43 +++
security/tomoyo/include/tomoyo.h | 513 +
2 files
1 - 100 of 3816 matches
Mail list logo
