[lxc-devel] [RFC 0/8] Unprivileged container creation and use

Stéphane Graber stgraber at ubuntu.com
Tue Jul 23 08:39:35 UTC 2013


On Mon, Jul 22, 2013 at 10:15:17AM -0500, Serge Hallyn wrote:
> Thanks for the review, Stéphane.
> 
> So the next thing I was wanting to do (beside fixing lxc-destroy and
> having the ubuntu-cloud template properly handle cached images and
> locking in custom lxcpaths for unprivileged users) was the networking.
> I have a question on that.
> 
> Originally I was going to have /etc/lxc/lxc-usernet be a control file
> with entries like:
> 
> serge veth lxcbr0 2
> 
> meaning serge can attach to veths to lxcbr0.  Mind you I'm not sure
> anything but veth makes sense for unprivileged users, but I don't want
> to lock other things out right now.
> 
> Then /run/lxc/nics was going to track the number of already in-use
> nics per user.
> 
> The problem with that will be similar to the problem I had with locking
> for the api:  when a container exits, the monitor would have to drop
> the count again.  So if the monitor actually dies a hard death, the
> user could end up with no active allocations, but /run/lxc/nics saying
> he was at his quota.
> 
> One alternative is to simply chown /sys/class/net/$veth to $user, then
> check the number of $user-owned veths instead of checking /run/lxc/nics
> for a count.
> 
> Are there any other ideas?
> 
> -serge

We could encode the uid in the veth name on the host, then count those
directly at startup time. That should be faster than iterating through
procfs to figure out what container is owned by who and in what bridge.

The downside of this approach though is that we'd have to ban the
lxc.network option allowing you to change the host interface name or use
that as a suffix for lxc-<uid>-<whatever the user set in their config>.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130723/63091e94/attachment.pgp>


More information about the lxc-devel mailing list