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...
>

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

2016-09-01 Thread arnaud gaboury 
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.

>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...
   │ │ ├─973 /usr/sbin/saslaut...
   │ │ └─974 /usr/sbin/saslaut...
   │ ├─spamassassin.service
   │ │ └─27341 /usr/bin/perl -T ...
   │ ├─system-clamd.slice
   │ │ └─clamd@amavisd.service
   │ │   └─27332 /usr/sbin/clamd -...
   │ ├─systemd-journald.service
   │ │ └─904 /usr/lib/systemd/...
   │ ├─systemd-logind.service
   │ │ └─936 /usr/lib/systemd/...
   │