> I'll be dropping all the unprivileged-mounts stuff - it looks like
> it was a bit early, and that a new patch series against 2.6.27-rc1
Yeah, I guess we can wait a few more years ;) -^^^
Miklos
___
Containers mailing list
[EMAIL PROTECTE
> Right, I figure if the normal action is to always do
> mnt->user = current->fsuid, then for the special case we
> pass a uid in someplace. Of course... do we not have a
> place to do that? Would it be a no-no to use 'data' for
> a non-fs-specific arg?
I guess it would be OK for bind, but not
On Wed, 25 Apr 2007 17:18:12 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > - refine adding "nosuid" and "nodev" flags for unprivileged mounts:
> > o add "nosuid", only if mounter doesn't have CAP_SETUID capability
> > o add "nodev", o
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> >>
> >> Are there other permission checks that mount is doing that we
> >> care about.
> >
> > Not mount itself, but in looking up /share/fa/root/h
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>>
>> Are there other permission checks that mount is doing that we
>> care about.
>
> Not mount itself, but in looking up /share/fa/root/home/fa,
> user fa doesn't have the rights to read /share, and b
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> >> Miklos Szeredi wrote:
> >> >
> >> > Andrew, please skip this patch, for now.
> >> >
> >> > Serge found a problem with the fsuid approach: setfsuid
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting H. Peter Anvin ([EMAIL PROTECTED]):
>> Miklos Szeredi wrote:
>> >
>> > Andrew, please skip this patch, for now.
>> >
>> > Serge found a problem with the fsuid approach: setfsuid(nonzero) will
>> > remove filesystem related capabilities. So
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> >> From: Miklos Szeredi <[EMAIL PROTECTED]>
> >>
> >> - refine adding "nosuid" and "nodev" flags for unprivileged mounts:
> >> o add "nosuid", only if mounter doesn't have CAP_SETUID capability
> >
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> From: Miklos Szeredi <[EMAIL PROTECTED]>
>>
>> - refine adding "nosuid" and "nodev" flags for unprivileged mounts:
>> o add "nosuid", only if mounter doesn't have CAP_SETUID capability
>> o add "nodev", only if mounter doesn't have CAP_MKNOD c
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
> Miklos Szeredi wrote:
> >
> > Andrew, please skip this patch, for now.
> >
> > Serge found a problem with the fsuid approach: setfsuid(nonzero) will
> > remove filesystem related capabilities. So even if root is trying to
> > set the "user=UID" flag
Miklos Szeredi wrote:
>
> Andrew, please skip this patch, for now.
>
> Serge found a problem with the fsuid approach: setfsuid(nonzero) will
> remove filesystem related capabilities. So even if root is trying to
> set the "user=UID" flag on a mount, access to the target (and in case
> of bind, t
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> - refine adding "nosuid" and "nodev" flags for unprivileged mounts:
> o add "nosuid", only if mounter doesn't have CAP_SETUID capability
> o add "nodev", only if mounter doesn't have CAP_MKNOD capability
>
> - allow unprivileged forced unmoun
David Miller <[EMAIL PROTECTED]> wrote:
> Is it possible for your changes to be purely networking
> and not need those changes outside of the networking?
See my latest patchset release. I've reduced the dependencies on
non-networking changes to:
(1) Oleg Nesterov's patch to change cancel_dela
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Ah yes, it says nothing about what the returned value means...
Yeah... If you could amend that as part of your patch, that'd be great.
David
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-f
On 04/25, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Yes sure. Note that this is documented:
> >
> > /*
> > * Kill off a pending schedule_delayed_work(). Note that the work
> > callback
> > * function may still be running on return from cancel_delayed_
On Wed, Apr 25 2007, Jens Axboe wrote:
> On Wed, Apr 25 2007, Vasily Tarasov wrote:
> > >> @@ -1806,7 +1765,11 @@ static int cfq_may_queue(request_queue_t
> > >> * so just lookup a possibly existing queue, or return 'may
> > >> queue'
> > >> * if that fails
> > >> */
On Wed, Apr 25, 2007 at 09:18:28AM +0200, Miklos Szeredi wrote:
> > > The following extra security measures are taken for unprivileged
> > > mounts:
> > >
> > > - usermounts are limited by a sysctl tunable
> > > - force "nosuid,nodev" mount options on the created mount
> >
> > The original use
On Wed, Apr 25 2007, Jens Axboe wrote:
> On Tue, Apr 24 2007, Vasily Tarasov wrote:
> > @@ -1806,7 +1765,11 @@ static int cfq_may_queue(request_queue_t
> > * so just lookup a possibly existing queue, or return 'may queue'
> > * if that fails
> > */
> > - cfqq = cfq_find_cfq_hash(cf
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Yes sure. Note that this is documented:
>
> /*
>* Kill off a pending schedule_delayed_work(). Note that the work
> callback
>* function may still be running on return from cancel_delayed_work().
> Run
>* flush_workqueue(
On Wed, Apr 25 2007, Vasily Tarasov wrote:
> >> @@ -1806,7 +1765,11 @@ static int cfq_may_queue(request_queue_t
> >> * so just lookup a possibly existing queue, or return 'may queue'
> >> * if that fails
> >> */
> >> - cfqq = cfq_find_cfq_hash(cfqd, key, tsk->ioprio);
> >> + cic = cfq
>> @@ -1806,7 +1765,11 @@ static int cfq_may_queue(request_queue_t
>> * so just lookup a possibly existing queue, or return 'may queue'
>> * if that fails
>> */
>> -cfqq = cfq_find_cfq_hash(cfqd, key, tsk->ioprio);
>> +cic = cfq_get_io_context_noalloc(cfqd, tsk);
>> +i
From: Miklos Szeredi <[EMAIL PROTECTED]>
- refine adding "nosuid" and "nodev" flags for unprivileged mounts:
o add "nosuid", only if mounter doesn't have CAP_SETUID capability
o add "nodev", only if mounter doesn't have CAP_MKNOD capability
- allow unprivileged forced unmount, but only fo
From: Vasily Tarasov <[EMAIL PROTECTED]>
>> -if (key != CFQ_KEY_ASYNC)
>> +if (!is_sync)
>> cfq_mark_cfqq_idle_window(cfqq);
>> +else
>> +cfq_mark_cfqq_sync(cfqq);
>
> Woops, should be
>
> if (is_sync) {
>
On Tue, Apr 24 2007, Vasily Tarasov wrote:
> @@ -1806,7 +1765,11 @@ static int cfq_may_queue(request_queue_t
>* so just lookup a possibly existing queue, or return 'may queue'
>* if that fails
>*/
> - cfqq = cfq_find_cfq_hash(cfqd, key, tsk->ioprio);
> + cic = cfq_ge
> > The following extra security measures are taken for unprivileged
> > mounts:
> >
> > - usermounts are limited by a sysctl tunable
> > - force "nosuid,nodev" mount options on the created mount
>
> The original userspace "user=" solution also implies the "noexec"
> option by default (you ca
25 matches
Mail list logo
