lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100519190510.GZ25951@kernel.dk>
Date:	Wed, 19 May 2010 21:05:11 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [patch] pipe: add support for shrinking and growing pipes

On Wed, May 19 2010, Jens Axboe wrote:
> On Wed, May 19 2010, Linus Torvalds wrote:
> > 
> > 
> > On Wed, 19 May 2010, Miklos Szeredi wrote:
> > > 
> > > One issue I see is that it's possible to grow pipes indefinitely.
> > > Should this be restricted to privileged users?
> > 
> > Yes. But perhaps only if it grows past the default (or perhaps "default*2" 
> > or similar). That way a normal user could shrink the pipe buffers, and 
> > then grow them again if he wants to.
> 
> That's still a bit arbitrary, I don't think allowing default*2 only for
> non-root is going to be hugely interesting. But limiting makes sense,
> but lets at least allow a larger max limit for the normal user. I'm
> suspecting that the media application that wants to use this will not be
> running as root, and we don't make the feature properly available to the
> ones that want to use it, then we may as well not do it.
> 
> Or we could expose a sysctl for instance that holds the max non-root
> size. And make that default to default*16 or something. How does that
> sound?
> 
> > Oh, and I think you need to also require that there be at least two 
> > buffers. Otherwise we can't guarantee POSIX behavior, I think.
> 
> Good point, and at least that part is easily doable :-)

So I updated the patch, that branch was pretty ancient... The fcntl pipe
numbers were also screwed up, so got that fixed. New patch is here:

http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=23dcb845246946aeda5a5e398c6911381ad28365

and I implemented a /proc/sys/fs/pipe-max-pages addon, that part is
here:

http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=6ef1fd2ea2fdba7a47706a46f0ca564ab2c46a52

Totally untested.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ