Re: [systemd-devel] moving a directory let me with a 65534:65534 owner/group directory

2016-09-01 Thread arnaud gaboury 
On Thu, Sep 1, 2016 at 4:24 PM arnaud gaboury 
wrote:

> On Thu, Sep 1, 2016 at 2:02 PM Lennart Poettering 
> wrote:
>
>> On Thu, 01.09.16 10:47, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>>
>> > I have been moving directories and files between my host and my
>> container
>> > many times since more than one year with no issues. Host is Archlinux
>> and
>> > container Fedora 24 (upgrade to 24 is quite recent: no more than 2
>> months).
>> >
>> > I moved a directory today from host to container and this let me, for
>> the
>> > first time, with a directory in the container owned by 65534:65534.
>> > > > privileges, as opposed to an ordinary (i.e., *non-privileged*) user.
>> This
>> > UID is often used for individuals accessing the system remotely via FTP
>> or
>> > HTTP[0] >
>>
>> Uh, oh. My gues is this: you are using user namespaces (wich is the
>> default these days if you use systemd-nspawn@.service), and I nevre
>> updated the copy logic in machined to deal with that...
>>
>
I rebuilt my kernel with removing user namespace (as it is set):
 # CONFIG_USER_NS is not set

Here was my container output:

[poisonivy@thetradinghall]/% ls -al
total 16K
dr-xr-xr-x   1 363397120 363397120  198 Sep  1 15:18 ./
dr-xr-xr-x   1 363397120 363397120  198 Sep  1 15:18 ../
dr-xr-xr-x   1 363397120 3633971200 Feb  3  2016 boot/
drwxrwxr-x   1 363397120 363397120   62 Aug 26 19:59 db/
drwxr-xr-x   7 root  root   440 Sep  1 17:33 dev/
drwxr-xr-x   1 363397120 363397120 4.1K Sep  1 15:34 etc/
drwxr-xr-x   1 363397120 363397120   76 Feb  3  2016 home/
drwxrwxrwx   1 363397120 3633971200 Aug 28 13:47 keybase/
drwxr-xr-x   1 363397120 3633971200 Feb  3  2016 media/
drwxr-xr-x   1 363397120 3633971200 Feb  3  2016 mnt/
drwxr-xr-x   1 363397120 363397120   56 Feb  3  2016 opt/
dr-xr-xr-x 376 root  root 0 Sep  1 17:33 proc/
dr-xr-x---   1 363397120 363397120  378 Sep  1 15:32 root/
drwxr-xr-x  32 root  root   800 Sep  1 17:34 run/
drwxr-xr-x   1 root  root 6 Mar  3 17:43 share/
drwxr-xr-x   1 363397120 3633971200 Feb  3  2016 srv/
drwxrwxr-x   1 363397120 363397130  242 Sep  1 16:34 storage/
drwxr-xr-x   9 root  root   180 Sep  1 17:33 sys/
drwxrwxrwt  11 root  root   220 Sep  1 17:39 tmp/
drwxr-xr-x   1 363397120 363397120  100 Dec 14  2015 usr/
drwxr-xr-x   1 363397120 363397120  194 Mar 19 18:29 var/
-rw-r--r--   1 363397120 3633971200 Sep  1 15:18 .autorelabel
lrwxrwxrwx   1 363397120 3633971207 Feb  3  2016 bin -> usr/bin/
lrwxrwxrwx   1 363397120 3633971207 Feb  3  2016 lib -> usr/lib/
lrwxrwxrwx   1 363397120 3633971209 Feb  3  2016 lib64 -> usr/lib64/
lrwxrwxrwx   1 root  root 8 Feb  3  2016 sbin -> usr/sbin/
-

Back with user namespace set to Y, output is correct (except the nobody
story).


> Or in other words, it's a bug in machined.
>>
>> I filed a github issue to keep track of this, so that we can get this
>> fixed:
>>
>> https://github.com/systemd/systemd/issues/4078
>
>
> Thank you for opening the issue. I have been reading quite a lot about
> this on the past few hours. Most of such issues arise with NTFS, which is
> not my case
> # mount
> /dev/sdb1 on / type btrfs
> (rw,noatime,compress=lzo,ssd,space_cache,autodefrag,subvolid=266,subvol=/rootvol)
> ...
>
>  if it can help, from container:
> ---
> root@thetradinghall ➤➤ / # lsattr
>  ./usr
> lsattr: Inappropriate ioctl for device While reading flags on ./run
>  ./boot
> lsattr: Inappropriate ioctl for device While reading flags on ./dev
>  ./home
>  ./media
>  ./mnt
>  ./opt
> lsattr: Inappropriate ioctl for device While reading flags on ./proc
>  ./root
>  ./srv
> lsattr: Inappropriate ioctl for device While reading flags on ./sys
> lsattr: Inappropriate ioctl for device While reading flags on ./tmp
>  ./etc
>  ./var
>  ./db
>  ./storage
>  ./share
> lsattr: Operation not supported While reading flags on ./sbin
>  ./keybase
> lsattr: Operation not supported While reading flags on ./bin
> lsattr: Operation not supported While reading flags on ./lib
> lsattr: Operation not supported While reading flags on ./lib64
> -
>
> This issue is new and have been able to cp/mv from host to container and
> preserve file/folders attributes until now. Something in my recent upgrades
> have done these changes.
>
>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

Re: [systemd-devel] moving a directory let me with a 65534:65534 owner/group directory

2016-09-01 Thread arnaud gaboury 
On Thu, Sep 1, 2016 at 2:02 PM Lennart Poettering 
wrote:

> On Thu, 01.09.16 10:47, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
> > I have been moving directories and files between my host and my container
> > many times since more than one year with no issues. Host is Archlinux and
> > container Fedora 24 (upgrade to 24 is quite recent: no more than 2
> months).
> >
> > I moved a directory today from host to container and this let me, for the
> > first time, with a directory in the container owned by 65534:65534.
> >  > privileges, as opposed to an ordinary (i.e., *non-privileged*) user. This
> > UID is often used for individuals accessing the system remotely via FTP
> or
> > HTTP[0] >
>
> Uh, oh. My gues is this: you are using user namespaces (wich is the
> default these days if you use systemd-nspawn@.service), and I nevre
> updated the copy logic in machined to deal with that...
>
> Or in other words, it's a bug in machined.
>
> I filed a github issue to keep track of this, so that we can get this
> fixed:
>
> https://github.com/systemd/systemd/issues/4078


Thank you for opening the issue. I have been reading quite a lot about this
on the past few hours. Most of such issues arise with NTFS, which is not my
case
# mount
/dev/sdb1 on / type btrfs
(rw,noatime,compress=lzo,ssd,space_cache,autodefrag,subvolid=266,subvol=/rootvol)
...

 if it can help, from container:
---
root@thetradinghall ➤➤ / # lsattr
 ./usr
lsattr: Inappropriate ioctl for device While reading flags on ./run
 ./boot
lsattr: Inappropriate ioctl for device While reading flags on ./dev
 ./home
 ./media
 ./mnt
 ./opt
lsattr: Inappropriate ioctl for device While reading flags on ./proc
 ./root
 ./srv
lsattr: Inappropriate ioctl for device While reading flags on ./sys
lsattr: Inappropriate ioctl for device While reading flags on ./tmp
 ./etc
 ./var
 ./db
 ./storage
 ./share
lsattr: Operation not supported While reading flags on ./sbin
 ./keybase
lsattr: Operation not supported While reading flags on ./bin
lsattr: Operation not supported While reading flags on ./lib
lsattr: Operation not supported While reading flags on ./lib64
-

This issue is new and have been able to cp/mv from host to container and
preserve file/folders attributes until now. Something in my recent upgrades
have done these changes.


> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] moving a directory let me with a 65534:65534 owner/group directory

2016-09-01 Thread Lennart Poettering 
On Thu, 01.09.16 10:47, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> I have been moving directories and files between my host and my container
> many times since more than one year with no issues. Host is Archlinux and
> container Fedora 24 (upgrade to 24 is quite recent: no more than 2 months).
> 
> I moved a directory today from host to container and this let me, for the
> first time, with a directory in the container owned by 65534:65534.
>  privileges, as opposed to an ordinary (i.e., *non-privileged*) user. This
> UID is often used for individuals accessing the system remotely via FTP or
> HTTP[0] >

Uh, oh. My gues is this: you are using user namespaces (wich is the
default these days if you use systemd-nspawn@.service), and I nevre
updated the copy logic in machined to deal with that...

Or in other words, it's a bug in machined.

I filed a github issue to keep track of this, so that we can get this
fixed:

https://github.com/systemd/systemd/issues/4078

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] moving a directory let me with a 65534:65534 owner/group directory

2016-09-01 Thread arnaud gaboury 
On Thu, Sep 1, 2016 at 12:47 PM arnaud gaboury 
wrote:

> I have been moving directories and files between my host and my container
> many times since more than one year with no issues. Host is Archlinux and
> container Fedora 24 (upgrade to 24 is quite recent: no more than 2 months).
>
> I moved a directory today from host to container and this let me, for the
> first time, with a directory in the container owned by 65534:65534.
>  privileges, as opposed to an ordinary (i.e., *non-privileged*) user. This
> UID is often used for individuals accessing the system remotely via FTP or
> HTTP[0] >
> From host, the directory is correctly seen as a root:root
>
> --
> # ls -al
> /var/lib/machines/poppy/storage/tth-blog/pelican-themes/material-TTH/static
> drwxr-xr-x 1 root  root  58 Sep  1 12:10 css/
> --
>
> I can't change owner/group ID from inside the container, which is of
> course very annoying as my folders and their contents are unusable.
>
>
> I didn't change anything in the way my container is mounted:
>
> $ cat /etc/fstab
> -
> LABEL=poppy-root /var/lib/machines/poppy
>  btrfs   rw,noatime,autodefrag,compress=lzo,ssd,subvol=rootvol
>  0   0
> -
> The container is started at boot time with systemd-nspawn@poppy.service
> (poppy is the container name)
>
>
> $ systemctl status systemd-nspawn@poppy.service
>
> ● systemd-nspawn@poppy.service - Container poppy
>Loaded: loaded (/usr/lib/systemd/system/systemd-nspawn@.service;
> enabled; vendor preset: dis
>Active: active (running) since Mon 2016-08-29 00:09:08 CEST; 3 days ago
>  Docs: man:systemd-nspawn(1)
>  Main PID: 612 (systemd-nspawn)
>Status: "Container running."
>CGroup: /machine.slice/systemd-nspawn@poppy.service
>├─612 /usr/bin/systemd-nspawn --quiet --keep-unit --boot
> --link-journal=try-guest --
>├─init.scope
>│ └─617 /usr/lib/systemd/...
>├─system.slice
>│ ├─console-getty.service
>│ │ └─991 /sbin/agetty --no...
>│ ├─dbus.service
>│ │ └─945 /usr/bin/dbus-dae...
>│ ├─dovecot.service
>│ │ ├─ 1016 /usr/sbin/dovecot
>│ │ ├─ 1431 dovecot/lmtp
>│ │ ├─ 1432 dovecot/anvil
>│ │ ├─ 1433 dovecot/log
>│ │ ├─ 1435 dovecot/config
>│ │ ├─ 1436 dovecot/lmtp
>│ │ ├─ 1437 dovecot/lmtp
>│ │ ├─ 1438 dovecot/lmtp
>│ │ ├─ 1439 dovecot/lmtp
>│ │ ├─ 1440 dovecot/lmtp
>│ │ ├─ 1441 dovecot/lmtp
>│ │ ├─ 1442 dovecot/lmtp
>│ │ ├─ 1443 dovecot/lmtp
>│ │ ├─ 1444 dovecot/lmtp
>│ │ ├─ 3222 dovecot/imap-login
>│ │ ├─ 3226 dovecot/imap
>│ │ ├─ 4129 dovecot/imap-login
>│ │ ├─ 4167 dovecot/imap
>│ │ ├─ 6412 dovecot/ssl-params
>│ │ ├─14815 dovecot/imap-login
>│ │ └─14819 dovecot/imap
>│ ├─nginx.service
>│ │ ├─1458 nginx: master pro...
>│ │ ├─1459 nginx: worker proces
>│ │ ├─1460 nginx: worker proces
>│ │ ├─1461 nginx: worker proces
>│ │ ├─1462 nginx: worker proces
>│ │ ├─1463 nginx: worker proces
>│ │ ├─1464 nginx: worker proces
>│ │ ├─1465 nginx: worker proces
>│ │ └─1466 nginx: worker proces
>│ ├─opendkim.service
>│ │ └─10182 /usr/sbin/opendki...
>│ ├─php-fpm.service
>│ │ ├─ 984 php-fpm: master p...
>│ │ ├─1445 php-fpm: pool own...
>│ │ ├─1446 php-fpm: pool own...
>│ │ ├─1447 php-fpm: pool own...
>│ │ ├─1448 php-fpm: pool own...
>│ │ ├─1449 php-fpm: pool own...
>│ │ ├─1450 php-fpm: pool www...
>│ │ ├─1451 php-fpm: pool www...
>│ │ ├─1452 php-fpm: pool www...
>│ │ └─1454 php-fpm: pool www...
>│ ├─polkit.service
>│ │ └─10026 /usr/lib/polkit-1...
>│ ├─postfix.service
>│ │ ├─ 1096 /usr/libexec/post...
>│ │ ├─ 1098 qmgr -l -t unix -u
>│ │ ├─ 1817 tlsmgr -l -t unix -u
>│ │ └─20925 pickup -l -t unix -u
>│ ├─postgresql.service
>│ │ ├─1009 /usr/bin/postgres...
>│ │ ├─1049 postgres: checkpo...
>│ │ ├─1050 postgres: writer ...
>│ │ ├─1051 postgres: wal wri...
>│ │ ├─1052 postgres: autovac...
>│ │ └─1053 postgres: stats c...
>│ ├─redis.service
>│ │ └─976 /usr/bin/redis-se...
>│ ├─saslauthd.service
>│ │ ├─970 /usr/sbin/saslaut...
>│ │ ├─971 /usr/sbin/saslaut...
>│ │ ├─972 /usr/sbin/saslaut...
>