On Mon, 2007-04-16 at 14:16 -0500, Serge E. Hallyn wrote:
This patch introduces a new proc interface that exposes all the
propagation
trees within the namespace.
It walks through each off the mounts in the namespace, and prints
the following information.
mount-id: a unique mount
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user hallyn does mount --bind / /home/hallyn/root
2. (...)
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser more clear than usermnt? What is allowed to the
user?
Interesting
So far even today these things can happen, however they are sufficiently
unlikely the tools don't account for them.
Once a hostile user can cause them things are more of a problem.
(Unless you want to tackle each problem legacy tool one at a time to
remove problems -
[double freeing of struct utrace leading to oops in
__rcu_process_callbacks]
Hi, Roland,
utrace debugging you've put into 2.6.21-rc6-mm1 helped. Two double-frees
reproduced:
1) BUG at kernel/utrace.c:176
rcu_utrace_free
utrace_reap
utrace_release_task
From: Evgeny Kravtsunov [EMAIL PROTECTED]
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() and
br_stp_recalculate_bridge_id() in which one of the addresses
is unsigned char *, and thus may not be
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser more clear than usermnt? What is allowed to the
I think so, yes. One makes it clear that we're talking about allowing
user (somethings :), one might
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
---
diff --git
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
If MNT_USERMNT flag is not set in the target vfsmount, then
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED]
Hi Pavel,
At some point in time, I wrote:
So, now we have two locks protecting cache_chain? Please explain why
you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
Because OOM can actually happen with this mutex locked. For example
kmem_cache_create() locks it and calls
Pekka J Enberg wrote:
Hi Pavel,
At some point in time, I wrote:
So, now we have two locks protecting cache_chain? Please explain why
you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
Because OOM can actually happen with this mutex locked. For example
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
MNT_USER and MNT_USERMNT? I claim no way will people keep those
straight. How about MNT_ALLOWUSER and MNT_USER?
Umm, is allowuser more clear than usermnt? What is allowed to the
I think so, yes. One makes it clear that we're
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
Why are directory permissions not sufficient to allow/deny non-priveleged
mounts?
I don't understand that contention yet.
The same scenarios laid out previously in this thread. I.e.
1. user
Pavel Emelianov [EMAIL PROTECTED] writes:
There are many places in the kernel where the construction like
foo = list_entry(head-next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
I'm a bit lost about what is currently done and who advocates for what.
It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
propagated. In the /share rbind+chroot example, I assume the admin
would start by doing
mount --bind /share /share
mount --make-slave
I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some extent we have to avoid confusing suid
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define NR_SLABS_TO_SHOW 10
-- Dave
mount --make-rshared /
mkdir -p /mnt/ns/$USER
mount --rbind / /mnt/ns/$USER
mount --make-rslave /mnt/ns/$USER
This was my main point - that the tree in which users can mount will be
a slave of /, so that propagating the are user mounts allowed flag
among peers is safe and intuitive.
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote:
I'm a bit lost about what is currently done and who advocates for what.
It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
propagated. In the /share rbind+chroot example, I assume the admin
would start by doing
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 15:49:30 +0400
From: Evgeny Kravtsunov [EMAIL PROTECTED]
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() and
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Mon, 16 Apr 2007 16:08:25 +0400
Otherwise the following calltrace will lead to a wrong
lockdep warning:
neigh_proxy_process()
`- lock(neigh_table-proxy_queue.lock);
arp_redo /* via tbl-proxy_redo */
arp_process
neigh_event_ns
Miklos Szeredi [EMAIL PROTECTED] writes:
I'm still not sure, what your problem is.
My problem right now is that I see a serious complexity escalation in
the user interface that we must support indefinitely.
I see us taking a nice powerful concept and seriously watering it down.
To some
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 12:55:41 -0700
David Miller wrote:
From: Pavel Emelianov [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 15:49:30 +0400
From: Evgeny Kravtsunov [EMAIL PROTECTED]
compare_ether_addr() implicitly requires that the addresses
The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.
compare_ether_addr() implicitly requires that the addresses
passed are 2-bytes aligned in memory.
This is not true for br_stp_change_bridge_id() and
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 13:37:23 -0700
The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.
compare_ether_addr() implicitly requires that the addresses
passed are
David Miller a écrit :
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 13:37:23 -0700
The previous patch relied on the bridge id being aligned by
the compiler (which happens as a side effect). So please use
this instead.
compare_ether_addr() implicitly requires that the
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 17 Apr 2007 23:24:36 +0200
I suspect you missed part of Stephen patch :
(maybe some mailer problem...)
My bad, sorry :(
I pushed the other version of the fix to Linus just now.
I'll put Stephen's version in if he sends me a fixup relative
to
On Mon, 16 Apr 2007 14:23:26 +0400 Pavel Emelianov wrote:
If the kernel OOPS-ed or BUG-ed then it probably should
considered as tainted. Use die_counter introduced by many
architectures to determine whether or not the kernel died.
This saves a lot of time explaining oddities in the
On Tue, Apr 17, 2007 at 03:18:56PM +0400, Pavel Emelianov wrote:
There are many places in the kernel where the construction like
foo = list_entry(head-next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head,
31 matches
Mail list logo
