[lxc-users] lxc-attach -L file permissions

2019-07-30 Thread Christoph Willing
I've recently changed my logging mechanism for a privileged
container to use "lxc-attach -L file -- command". It works fine except
that the resulting pty log file is owned by root with permissions of
0600. Is there a way I can easily change that default, for instance to 0644?

I'm using lxc-2.0.9_d3a03247 and both my user and root umasks are 0022.

Thanks for any insights,
chris
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users


Re: [lxc-users] uid range not allowed

2016-07-28 Thread Christoph Willing
Sorry for the duplicate - I had earlier posted to the list from the 
wrong email identity and presumed it would be rejected as coming from a 
non-subscriber but looks like it has just been waved through now.


The immediate problem was solved - I needed to add an additional 
"chris:1000:1" to /etc/sub{u,g}id


chris


On 23/07/16 17:08, Chris Willing wrote:

I'm following the guide to run X apps in a container at:
 https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

As a starting point, I have a normal unprivileged container running
perfectly. However when I change the id_map configuration to look like:
lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535

the container fails to start, claiming:

chris@d6:~/.local/share/lxc$ lxc-start -n x11-test-x86_64 -F
newuidmap: uid range [1000-1001) -> [1000-1001) not allowed
lxc-start: start.c: lxc_spawn: 1161 failed to set up id mapping
...
...

Sure enough, if I comment out the lines:
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1

the container runs again - but it's that particular mapping that is
needed in this case.

I set up a log file to priority DEBUG but no extra clues there - it just
says the same thing.

I'm using:
   lxc-2.0.1
   cgmanager-0.39
with container config file attached.

Can anyone shed light on this problem please?

chris



___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users



___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] uid range not allowed

2016-07-23 Thread Christoph Willing

On 23/07/16 18:38, rob e wrote:



On 23/07/16 17:49, Christoph Willing wrote:

I'm following the guide to run X apps in a container at:
  https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

As a starting point, I have a normal unprivileged container running
perfectly. However when I change the id_map configuration to look like:
lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535

the container fails to start, claiming:

chris@d6:~/.local/share/lxc$ lxc-start -n x11-test-x86_64 -F
newuidmap: uid range [1000-1001) -> [1000-1001) not allowed
lxc-start: start.c: lxc_spawn: 1161 failed to set up id mapping
...
...

Sure enough, if I comment out the lines:
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1

the container runs again - but it's that particular mapping that is
needed in this case.

I set up a log file to priority DEBUG but no extra clues there - it
just says the same thing.

I'm using:
lxc-2.0.1
cgmanager-0.39
with container config file attached.

Can anyone shed light on this problem please?

chris




___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

umm .. I have exactly that setup (user and group id mapping) and it
works for me. It's what I use for desktop integration. Did you change
the /etc/sub* files  as per the following ?
https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/


[snip]

Yes, from that site I already had chris:10:65536

What was missing was a chris:1000:1 entry, so now I have:
chris:1000:1
chris:10:65536

which is allowing container startup without any error.

I see you have a root:1000:1 entry - that didn't work for me. I guess 
you're running yours as privileged containers?


chris



And the /etc/sub* files (modified to protect the innocent ...)
/etc/subuid

:10:65536
:165536:65536
root:165536:65536
:231072:65536
root:1000:1

/etc/subgid

:10:65536
:165536:65536
root:165536:65536
:231072:65536
root:1000:1




___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] uid range not allowed

2016-07-23 Thread Christoph Willing

On 23/07/16 18:16, Andreas Vögele wrote:

Christoph Willing writes:


I'm following the guide to run X apps in a container at:
  https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

As a starting point, I have a normal unprivileged container running
perfectly. However when I change the id_map configuration to look
like:
lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535

the container fails to start, claiming:

chris@d6:~/.local/share/lxc$ lxc-start -n x11-test-x86_64 -F
newuidmap: uid range [1000-1001) -> [1000-1001) not allowed
lxc-start: start.c: lxc_spawn: 1161 failed to set up id mapping
[...]
Can anyone shed light on this problem please?


You've got to add the id to /etc/subuid and /etc/subgid. Example:

chris:1000:1
chris:10:65536


Thanks Andreas,

I had the second line but not the first. The container starts without 
error now.


chris

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] uid range not allowed

2016-07-23 Thread Christoph Willing

I'm following the guide to run X apps in a container at:
  https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/

As a starting point, I have a normal unprivileged container running 
perfectly. However when I change the id_map configuration to look like:

lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535

the container fails to start, claiming:

chris@d6:~/.local/share/lxc$ lxc-start -n x11-test-x86_64 -F
newuidmap: uid range [1000-1001) -> [1000-1001) not allowed
lxc-start: start.c: lxc_spawn: 1161 failed to set up id mapping
...
...

Sure enough, if I comment out the lines:
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1

the container runs again - but it's that particular mapping that is 
needed in this case.


I set up a log file to priority DEBUG but no extra clues there - it just 
says the same thing.


I'm using:
lxc-2.0.1
cgmanager-0.39
with container config file attached.

Can anyone shed light on this problem please?

chris


# Template used to create this container: 
/usr/share/lxc/templates/lxc-spbuilder-1402
# Parameters passed to the template: -a x86_64
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.name = eth0
lxc.network.hwaddr = 00:16:3e:d9:8e:4a
lxc.rootfs = /home/chris/.local/share/lxc/x11-test-x86_64/rootfs
lxc.rootfs.backend = dir

lxc.utsname = x11-test-x86_64

lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
lxc.mount.entry = /dev/video0 dev/video0 none bind,optional,create=file

#lxc.hook.pre-start = /home/chris/.local/share/lxc/precise-gui/setup-pulse.sh

lxc.mount.entry = /scratch/PKG/SBo/slackbuilds mnt/slackbuilds none 
bind,ro,create=dir 0 0
#lxc.mount.entry = /var/cache/spbuilder var/cache/spbuilder none 
bind,create=dir 0 0
lxc.mount.auto = proc:mixed sys:ro cgroup

lxc.tty = 4
lxc.pts = 1024

lxc.cgroup.devices.deny = a
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm

# we don't trust even the root user in the container, better safe than sorry.
# comment out only if you know what you're doing.
lxc.cap.drop = sys_module mknod mac_override mac_admin sys_time setfcap setpcap

# you can try also this alternative to the line above, whatever suits you 
better.
#lxc.cap.drop=sys_admin
#lxc.id_map = u 0 10 65536
#lxc.id_map = g 0 10 65536

lxc.id_map = u 0 10 1000
lxc.id_map = g 0 10 1000
#lxc.id_map = u 1000 1000 1
#lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] how can I unsubscribe this mail list?

2016-02-21 Thread Christoph Willing

On 22/02/16 11:37, bse...@asx.co.jp wrote:

Hi all

how can I unsubscribe this mail list?
Thanks!



___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users



Try clicking on the last link in every post's footer
(http://lists.linuxcontainers.org/listinfo/lxc-users) and look for the 
section "To unsubscribe from lxc-users, ..." towards the end of the 
resulting page; then do what is suggested there.


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Setting user environment for unprivileged containers

2014-07-03 Thread Christoph Willing



On 07/03/2014 11:46 PM, Serge Hallyn wrote:

Quoting Christoph Willing (chris.will...@iinet.net.au):

I'm trying to make unprivileged containers work nicely on Slackware
- with some success. After some updates (kernel config, latest
shadow, latest lxc, install cgmanager) I worked through steps at
https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/.
I've made a Slackware template with which I can create a working
normal privileged container. I then use Serge Hallyn's uidmapshift
on it and copy the resulting unprivileged container into
$USER/.local/share/lxc/ from where it can be run by the user. It all
works fine.

The only wrinkle is that before being able to run lxc-start for the
first time on an unprivileged container, the user must first run the
commands:
 sudo cgm create all $USER
 sudo cgm chown all $USER $(id -u) $(id -g)
 sudo cgm movepid all $USER $$
I'd like to avoid that if possible.

Interestingly,
- those commands only need to be run once in a given terminal
session (run lxc-start any number of times after that)
- those commands need to be run in any new terminal in which
lxc-start is to be run on an unprivileged container i.e. running
them in one terminal doesn't bless any new terminal sessions
- the commands don't work when executed from a script
- the commands don't work if executed by root on the user's behalf

Ideally this would be set up either at boot time for approved
users or whenever the approved users log in to the machine. I have
tried chmod'ing cgm to setuid root (not sure that would be a good
long term solution anyway) and it succeeded with first and last of
those commands but not the second (cgm chown ..).

Could someone explain how this is managed in other distros where
running unprivileged already works please? I have an uneasy feeling


Yup, it's done via pam_systemd.so


that its via PAM (the last of the prerequisites mentioned on
Stephane's page) but PAM is not used in Slackware and most unlikely
to be introduced.

BTW, the situation is exactly the same when using the download
template to run the available premade containers i.e. I don't
believe its a problem with the template I made myself. Anyway, this
is surely something to be arranged in the host, not in the container
itself.

Any description of how the user environment is set up and/or tips
about this would be greatly appreciated.


So what is the standard way that slackware does things like chowning
audio and cdrom devices to the user logging in on console?  I would
hook that with a script that creates, sets up, and chowns new cgroups
and moves the new user into it.


Thanks for the response Serge - it must have just crossed my last email 
with a solution I found that is, more or less, what you've suggested.


In Slackware, things like video, audio, cdrom etc., have their own 
groups and when a new user is created on the system, they're optionally 
made member of those groups. I've just made a new group (lxcusers - like 
vboxusers) and when users who are members of that group log in, their 
cgroups are set up. The breakthrough was finding that the cgroup setup 
script (which uses your cgm) should be sourced, not executed.


Its a bit clunky but it works and good enough for now.

chris


___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Setting user environment for unprivileged containers

2014-07-02 Thread Christoph Willing
I'm trying to make unprivileged containers work nicely on Slackware - 
with some success. After some updates (kernel config, latest shadow, 
latest lxc, install cgmanager) I worked through steps at 
https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/. 
I've made a Slackware template with which I can create a working normal 
privileged container. I then use Serge Hallyn's uidmapshift on it and 
copy the resulting unprivileged container into $USER/.local/share/lxc/ 
from where it can be run by the user. It all works fine.


The only wrinkle is that before being able to run lxc-start for the 
first time on an unprivileged container, the user must first run the 
commands:

sudo cgm create all $USER
sudo cgm chown all $USER $(id -u) $(id -g)
sudo cgm movepid all $USER $$
I'd like to avoid that if possible.

Interestingly,
- those commands only need to be run once in a given terminal session 
(run lxc-start any number of times after that)
- those commands need to be run in any new terminal in which lxc-start 
is to be run on an unprivileged container i.e. running them in one 
terminal doesn't bless any new terminal sessions

- the commands don't work when executed from a script
- the commands don't work if executed by root on the user's behalf

Ideally this would be set up either at boot time for approved users or 
whenever the approved users log in to the machine. I have tried 
chmod'ing cgm to setuid root (not sure that would be a good long term 
solution anyway) and it succeeded with first and last of those commands 
but not the second (cgm chown ..).


Could someone explain how this is managed in other distros where running 
unprivileged already works please? I have an uneasy feeling that its via 
PAM (the last of the prerequisites mentioned on Stephane's page) but PAM 
is not used in Slackware and most unlikely to be introduced.


BTW, the situation is exactly the same when using the download template 
to run the available premade containers i.e. I don't believe its a 
problem with the template I made myself. Anyway, this is surely 
something to be arranged in the host, not in the container itself.


Any description of how the user environment is set up and/or tips about 
this would be greatly appreciated.


chris
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users