Re: [PATCH] Add ability to set rlimits at container boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard, 

I have to disagree that it should require idmap. It is true that without idmap the container can freely set it's own rlimits, but I believe this functionality could be useful to containers that don't run /sbin/init. What I mean by that is application specific containers could have their limits set without the application having to set them, or even having to write a shim to set them. 

Ryan

On Sun, Feb 22, 2015 at 5:59 PM, Richard Weinberger <richard.weinberger@xxxxxxxxx> wrote:
On Fri, Jan 30, 2015 at 4:32 PM, Ryan Cleere <rcleere@xxxxxxxxx> wrote:
> I guess I don't really have an argument for or against removing some of them
> from <rlimits>. The original patch that I wrote and we use internally only
> allowed setting of RLIMIT_NOFILE, but when I went to publish it back to this
> list is was trivial to just make it a generic interface to all of the
> RLIMIT_* tunables. I don't have a need for them at this time, but I figured
> someone else might find them useful. But if this list can come up with a set
> we want included/excluded then the <rlimits> section can be modified
> accordingly. Although it might be confusing to an operator who is reading
> the setrlimit(2) manpage and can't understand why they can't set the limit
> they are interested in.

BTW: This should depend on idmap (user namespaces set up).
Without user namespaces root can bypass/reset all these limits.

--
Thanks,
//richard

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]