search for: cap_mknod

...llow 5) Now pppd work inside lxc: #pppd call reuters debug nodetach using channel 1 Using interface ppp0 Connect: ppp0 <--> /dev/pts/2 sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x567d90ae>] ... But such method has several drawbacks. 1) I do not want to give cap_mknod, no need extra holes. With cap_mknod you can make /de/block_device and using device.allow to give it the rights rwm. 2) libvirt-lxc has some analog of lxc/lxd options lxc.group.devices.allow ? lxc.cgroup.devices.allow = c 108:0 rwm And yes, I need run "mknod" and "echo" each...

...or is there a problem with system, libvirt or kernel? > I've not had any chance to try LXC + user namespaces + systemd yet, but > based on the list of things which fail, it seems like it might not be > detecting that it is inside a container. Seems almost like it has still > got the CAP_MKNOD permission and so is strying to start things it should > not have like udev, and various filesystems. > > Daniel I was able to reduce the problem by not using libvirt nor systemd. I've created a bash process inside user namespace with mapping root_inside<->root_outside. I'...

Hi there! I am trying to turn on user namespace by adding following lines to the config: <idmap> <uid start='0' target='0' count='100000'/> <gid start='0' target='0' count='100000'/> </idmap> As you can see the root in container is mapped to the root outside. I was expected to see no difference

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi lxc folks, the symptom my libvirt LXC container suffers from is: root@depot:/dev/net# ls -la total 0 drwxr-xr-x 2 root root 40 Jun 29 16:26 . drwxr-xr-x 5 root root 480 Jun 29 16:26 .. root@depot:/dev/net# mknod tun c 10 200 mknod: `tun': Operation not permitted The host is an up-to-date AMD64 Ubuntu raring on 3.8.0-25-generic that was

...uired if you don't need libvirt to chown()/setfilecon() disk images (dynamic_ownership in qemu.conf). CAP_SYS_ADMIN is going to be required if you want libvirt to mount some nfs based storage pools/create namespaces (note that libvirt creates a small namespace for qemu to run in - might need CAP_MKNOD then). Long story short, why bother with /system if you can't use it and not use /session instead? Michal

...missing something or is there a problem with system, libvirt or kernel? I've not had any chance to try LXC + user namespaces + systemd yet, but based on the list of things which fail, it seems like it might not be detecting that it is inside a container. Seems almost like it has still got the CAP_MKNOD permission and so is strying to start things it should not have like udev, and various filesystems. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -...

...4 12:07:37 +0100 Vegard Vesterheim <vegard.vesterheim at uninett.no> wrote: > # mknod -m 666 /dev/tty c 4 0 > mknod: `/dev/tty': Operation not permitted In the manual for the LXC driver this part of my question is answered: "The container init process will be started with CAP_MKNOD capability removed and blocked from re-acquiring it. As such it will not be able to create any device nodes in /dev or anywhere else in its filesystems." Further down the manual says: "Further block or character devices will be made available to containers depending on th...

...the > prepared one ...? Allowing the container direct access to the hosts' /dev would be a security flaw, so libvirt sets up a private /dev for the container. Allowing the container to use mknod would also be insecure, so we blocking mknod using both cgroups device ACL, and also droping the CAP_MKNOD capability. http://libvirt.org/drvlxc.html#devnodes Any device that the container is authorized to access per the XML configuration, will be pre-created in the container's /dev. To explicitly allow /dev/net/tun you need to tell libvirt about it. http://libvirt.org/formatdomain.html#eleme...

...ed > Allowing the container direct access to the hosts' /dev would be a > security flaw, so libvirt sets up a private /dev for the > container. Allowing the container to use mknod would also be > insecure, so we blocking mknod using both cgroups device ACL, and > also droping the CAP_MKNOD capability. > http://libvirt.org/drvlxc.html#devnodes Good to know. > Any device that the container is authorized to access per the XML > configuration, will be pre-created in the container's /dev. To > explicitly allow /dev/net/tun you need to tell libvirt about it. > http...

On Tue, 30 Apr 2019 at 10:48, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Apr 30, 2019 at 10:45:03AM +0100, Peter Crowther wrote: > > On Tue, 30 Apr 2019 at 10:40, Michal Privoznik <mprivozn@redhat.com> > wrote: > > > > > Is there any problem running libvirtd as root? > > > > > > Yes, in the regulated environment in which I

I have created a LXC container with debootstrap followed by virt-install like this: host=mylxc1 debootstrap wheezy /home/lxc/$host virt-install -c lxc:// -n $host --filesystem /home/lxc/$host,/ --ram 1024 I am confused about the /dev filesystem in this container. Specifically the device '/dev/tty'. >From inside the container: ~# ls -la /dev/tty ls: cannot access /dev/tty: No such

...YS_MODULE), + MAKE_CAP(CAP_SYS_RAWIO), + MAKE_CAP(CAP_SYS_CHROOT), + MAKE_CAP(CAP_SYS_PTRACE), + MAKE_CAP(CAP_SYS_PACCT), + MAKE_CAP(CAP_SYS_ADMIN), + MAKE_CAP(CAP_SYS_BOOT), + MAKE_CAP(CAP_SYS_NICE), + MAKE_CAP(CAP_SYS_RESOURCE), + MAKE_CAP(CAP_SYS_TIME), + MAKE_CAP(CAP_SYS_TTY_CONFIG), + MAKE_CAP(CAP_MKNOD), + MAKE_CAP(CAP_LEASE), + MAKE_CAP(CAP_AUDIT_WRITE), + MAKE_CAP(CAP_AUDIT_CONTROL), + MAKE_CAP(CAP_SETFCAP), + MAKE_CAP(CAP_MAC_OVERRIDE), + MAKE_CAP(CAP_MAC_ADMIN), + MAKE_CAP(CAP_SYSLOG), +}; + +static void fail(const char *fmt, ...) __attribute__((format(printf, 1, 2))); +static void fail(const...

This patchset applies to klibc mainline. As is it will probably collide with Maximilian's recent patch to rename run-init to switch_root posted last week. To boot an untrusted environment with certain capabilities locked out, we'd like to be able to drop the capabilities up front from early userspace, before we actually transition onto the root volume. This patchset implements this by