Bug 1356810
| Summary: | Fliesystem extended attributes in trusted namespace are not persisted after node reboot | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Mohamed Ashiq <mliyazud> |
| Component: | docker | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED NOTABUG | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | hchiramm, jhonce, kdudka, lsm5, mliyazud |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-18 14:24:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mohamed Ashiq
2016-07-15 06:03:50 UTC
This is either problem with the file system implementation or the containerized environment. There is no flag that the libattr users-pace library could use to tell kernel whether the attributes should persist a reboot or not. Not a bug in the attr package for sure. (In reply to Kamil Dudka from comment #2) > This is either problem with the file system implementation or the > containerized environment. There is no flag that the libattr users-pace > library could use to tell kernel whether the attributes should persist a > reboot or not. > > Not a bug in the attr package for sure. Yes, We do suspect it may be something wrong with the underlying FS. In this context it is XFS. We also did some isolation here and we noticed that the attributes we set from the container was not visible at times when we inspect from the HOST system. Thats one of the reason for opening this bug. But, you were fast to respond before updating this second scenario :). Can you please confirm libattr dont have a role in this scenario as well ? We are doing more isolation wrt container environment and also with underlying FS/XFS. We would like to eliminate the possibilities of libattr in both the scenarios. Sure I meant the attr package with all its subpackages, including libattr. It just implements library interface on top of the corresponding syscalls. There is nothing in libattr that could influence whether the extended attributes are propagated to the host file system or not. I am switching the component to docker as it takes care of the bind mounts. The SELinux xattrs are set at container creation time. It is up to the file system to maintain the Xattrs. As an experiment outside of docker, could you check the contexts on these directories before reboot? After creating the container ls -ldZ /etc/glusterfs /var/lib/glusterd /var/log/glusterfs After reboot, run the same command. If these labels are changing, then something in the boot is changing the labels. or the file system is broken. Nothing in docker should change them after the container creation? Kamil any update on this? (In reply to Daniel Walsh from comment #7) > Kamil any update on this? I am just the maintainer of libattr. This bug was assigned to me by mistake. Setting needinfo on Mohamed, who reported it originally... (In reply to Daniel Walsh from comment #6) > The SELinux xattrs are set at container creation time. It is up to the file > system to maintain the Xattrs. > > As an experiment outside of docker, could you check the contexts on these > directories before reboot? > > > After creating the container > > ls -ldZ /etc/glusterfs /var/lib/glusterd /var/log/glusterfs > > After reboot, run the same command. If these labels are changing, then > something in the boot is changing the labels. or the file system is broken. > > Nothing in docker should change them after the container creation? Dan, sorry for really late reply. I am able to see the labels on the host and container in these(/etc/glusterfs /var/lib/glusterd /var/log/glusterfs). The problem is on the LV's which was created inside the container and mounted in the container using a custom fstab. After reboot, the container is spawned instantly and few mountpoints are sometimes read-only and sometimes not mounted. (In reply to Mohamed Ashiq from comment #9) > (In reply to Daniel Walsh from comment #6) > > The SELinux xattrs are set at container creation time. It is up to the file > > system to maintain the Xattrs. > > > > As an experiment outside of docker, could you check the contexts on these > > directories before reboot? > > > > > > After creating the container > > > > ls -ldZ /etc/glusterfs /var/lib/glusterd /var/log/glusterfs > > > > After reboot, run the same command. If these labels are changing, then > > something in the boot is changing the labels. or the file system is broken. > > > > Nothing in docker should change them after the container creation? > > Dan, sorry for really late reply. I am able to see the labels on the host > and container in these(/etc/glusterfs /var/lib/glusterd /var/log/glusterfs). > The problem is on the LV's which was created inside the container and > mounted in the container using a custom fstab. After reboot, the container > is spawned instantly and few mountpoints are sometimes read-only and > sometimes not mounted. So these mountpoints were mounted using custom fstab. We were checking the mount points which was not mounted. As glusterfs was still setting few xattrs for checking(which was something unexpected), We thought the rest of the xattrs are lost. Does this mean there is no bug? Or at least on bug in docker? |