On Wednesday 2015-07-15 14:15, Cyrill Gorcunov wrote:
>Hello! Could you clarify please the following aspect: before the commit
>
> | commit 6944f2c8190f1c4319aeac748470c71b0ba45025
>
>if the AH module has no --ahspi argument passed to iptables then it
>became [0;0x] by default, but in -ma
On Thursday 2010-03-04 22:45, Eric W. Biederman wrote:
>
>So an unshare of the pid namespace that doesn't really take effect
>until we fork may actually be usable from pam, and in fact is probably
>the preferred implementation. It looks like neither openssh nor login
>from util-linux-ng will cope
On Tuesday 2010-03-02 16:03, Pavel Emelyanov wrote:
>> I agree with all the points you and Pavel you talked about but I don't
>> feel comfortable to have the current process to switch the pid namespace
>> because of the process tree hierarchy (what will be the parent of the
>> process when you
On Friday 2008-09-05 08:25, Patrick McHardy wrote:
>> > I hope so :) A different possiblity suggest by Pablo some time ago
>> > would be to mark untracked packets in skb->nfctinfo and not
>> > attach a conntrack at all.
>>
>> Indeed, I remember that :). I left that patch of the table time ago [1]
On Thursday 2008-09-04 22:58, Alexey Dobriyan wrote:
>In conntrack_mt_v0() "ct->status" can be used even for untracked connection,
>is this right?
Yes.
>For example, does setting IPS_NAT_DONE_MASK and IPS_CONFIRMED_BIT on
>untracked conntracked really necessary?
Does it even happen? Something
On Friday 2008-08-22 07:30, [EMAIL PROTECTED] wrote:
>
>We wait for untracked ct refcount to drop to 1 back:
>
> /* wait until all references to nf_conntrack_untracked are dropped */
> while (atomic_read(&nf_conntrack_untracked.ct_general.use) > 1)
> schedule();
>
>Conseq
On Thursday 2008-08-21 18:04, [EMAIL PROTECTED] wrote:
>Make untracked conntrack per-netns.
Why? It does not store any useful information per se, it is
merely used to add a third type of ct, iow:
(a) ct==NULL
(b) ct!=NULL
(c) ct==&untracked
mmap(2)'s return value for example has something simi
On Jan 8 2008 20:08, Miklos Szeredi wrote:
>> On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
>> > +static int reserve_user_mount(void)
>> > +{
>> > + int err = 0;
>> > +
>> > + spin_lock(&vfsmount_lock);
>> > + if (nr_user_mounts >= max_user_mounts && !capable(CAP_SYS_A
On Oct 9 2007 09:26, Vasily Averin wrote:
>
>On one of our servers timer interrupts (i.e irq0) are stops working. As result
>any kernel timers do not triggers and tasks waiting some signals from timers
>hangs forever.
What kernel.. and tried CONFIG_NO_HZ=n?
__
On Sep 21 2007 08:53, Randy Dunlap wrote:
>On Fri, 21 Sep 2007 17:35:43 +0400 Andrey Mirkin wrote:
>
>> From: Andrey Mirkin <[EMAIL PROTECTED]>
>>
>> Right now futexfs and inotifyfs have one magic 0xBAD1DEA, that looks a
>> little
>> bit confusing.
>> Use 0xBAD1DEA as magic for futexfs and 0x2B
On Sep 11 2007 08:22, Randy Dunlap wrote:
>> "cfs" control group subsystem.
>
>That looks odd, like it's a filesystem.
>What does cfs really mean?
http://en.wikipedia.org/wiki/CFS
(scnr)
It misses the C...something Filesystem tho.
Jan
--
__
On Sep 10 2007 22:58, Srivatsa Vaddagiri wrote:
>On Mon, Sep 10, 2007 at 10:53:34PM +0530, Srivatsa Vaddagiri wrote:
>> > cpuctl, cpuctrl, cpu_controller?
>>
>> *shrug* .. I used "cpuctlr" to mean "CPU Controller". Any other short names
>> would do. From your list, cpuctl or cpuctrl both qualifie
On Sep 10 2007 10:22, Andrew Morton wrote:
>> Unless folks have strong objection to it, I prefer "cptctlr", the way it is.
>
>Kernel code is write-rarely, read-often.
I think you mean __read_mostly. :-)
Jan
--
___
Containers mailing list
[E
On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
>+#ifdef CONFIG_FAIR_GROUP_SCHED
>+SUBSYS(cpuctlr)
>+#endif
cpuctl, cpuctrl, cpu_controller?
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
__
On Aug 27 2007 11:01, Joe Perches wrote:
>On Mon, 2007-08-27 at 11:30 +0400, Pavel Emelyanov wrote:
>> From: Alexey Dobriyan <[EMAIL PROTECTED]>
>>
>> One of the easiest things to isolate is the pid printed in kernel
>> log. There was a patch, that made this for arch-independent code,
>> this one
On Jun 25 2007 15:53, Patrick McHardy wrote:
>Vasily Averin wrote:
>> +static int early_drop(const struct nf_conntrack_tuple *orig)
>> +{
>> +unsigned int i, hash, cnt;
>> +int ret = 0;
>> +
>> +hash = hash_conntrack(orig);
>> +cnt = NF_CT_PER_BUCKET;
>> +
>> +for (i = 0;
>> +
This seems to have died and remain unmerged as of yet... resubmit?
On Apr 17 2007 12:58, Pavel Emelianov wrote:
>Date: Tue, 17 Apr 2007 12:58:47 +0400
>From: Pavel Emelianov <[EMAIL PROTECTED]>
>To: Andrew Morton <[EMAIL PROTECTED]>,
>Linux Kernel Mailing List <[EMAIL PROTECTED]>,
>[EM
On May 2 2007 15:32, Alexey Dobriyan wrote:
>--- a/include/linux/utrace.h
>+++ b/include/linux/utrace.h
>@@ -50,11 +50,30 @@ #include
>
> struct linux_binprm;
> struct pt_regs;
>-struct utrace;
>+struct task_struct;
> struct utrace_signal;
> struct utrace_regset;
> struct utrace_regset_view;
>
On Apr 26 2007 22:27, Miklos Szeredi wrote:
>> On Apr 25 2007 11:21, Eric W. Biederman wrote:
>> >>
>> >> Why did we want to use fsuid, exactly?
>> >
>> >- Because ruid is completely the wrong thing we want mounts owned
>> > by whomever's permissions we are using to perform the mount.
>>
>> Thin
On Apr 25 2007 11:21, Eric W. Biederman wrote:
>>
>> Why did we want to use fsuid, exactly?
>
>- Because ruid is completely the wrong thing we want mounts owned
> by whomever's permissions we are using to perform the mount.
Think nfs. I access some nfs file as an unprivileged user. knfsd, by
nat
On Apr 23 2007 12:25, Christoph Hellwig wrote:
>On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
>>
>> This patch implements the kthread helper functions kthread_start
>> and kthread_end which make it simple to support a kernel thread
>> that may decided to exit on it's own befo
On Apr 21 2007 10:57, Eric W. Biederman wrote:
>
>> tmpfs!
>
>tmpfs is a possible problem because it can consume lots of ram/swap.
>Which is why it has limits on the amount of space it can consume.
Users can gobble up all RAM and swap already today. (Unless they are
confined into an rlimit, whi
On Apr 21 2007 08:10, Eric W. Biederman wrote:
>>
>>> Define a new fs flag FS_SAFE, which denotes, that unprivileged
>>> mounting of this filesystem may not constitute a security problem.
>>>
>>> Since most filesystems haven't been designed with unprivileged
>>> mounting in mind, a thorough audit
On Apr 6 2007 16:16, H. Peter Anvin wrote:
>> >
>> > - users can use bind mounts without having to pre-configure them in
>> > /etc/fstab
>> >
>
> This is by far the biggest concern I see. I think the security implication of
> allowing anyone to do bind mounts are poorly understood.
$ whoami
mi
24 matches
Mail list logo
