Re: [systemd-devel] moving a directory let me with a 65534:65534 owner/group directory
On Thu, Sep 1, 2016 at 4:24 PM arnaud gabourywrote: > 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
On Thu, Sep 1, 2016 at 2:02 PM Lennart Poetteringwrote: > 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
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
On Thu, Sep 1, 2016 at 12:47 PM arnaud gabourywrote: > 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... >