Bug#910130: nautilus: Nautilus can't create directories while traversing NFSv4 referrals with ACLs
prunkdump
prunkdump at gmail.com
Wed Oct 3 07:30:19 BST 2018
Package: nautilus
Version: 3.26.3.1-1
Severity: normal
Dear Maintainer,
The 3.22.3-1+deb9u1 security update from stretch-security cause some
regression. This bug report was made from a Debian sid computer but the bug
also appear in stable.
On my network I have a directory tree exported with NFSv4 using referrals. For
example the exported path :
/dnfs/shares
Contain two referrals that redirect to some other path :
/dnfs/shares/Ressources
/dnfs/shares/Base
As this is a high school network, I have a users group "teachers" that have RWX
access on both using ACLs. The teachers group is not present in standand
user/group permissions.
So here the steps that lead to the bug. Say I'm a teacher user :
1) At start gio don't detect any WRITE access to the referrals. But maybe this
is normal.
~$ gio test /dnfs/shares/Ressources
nom d'affichage : Ressource
nom d'édition : Ressource
nom : Ressource
type : directory
taille : 4096
uri : file:///dnfs/shares/Ressources
attributs :
standard::type: 2
standard::name: Ressource
standard::display-name: Ressource
standard::edit-name: Ressource
standard::copy-name: Ressource
standard::icon: folder
standard::content-type: inode/directory
standard::fast-content-type: inode/directory
standard::size: 4096
standard::allocated-size: 4096
standard::symbolic-icon: folder-symbolic, folder
etag::value: 1538394987:592109
id::file: l38:1839867
id::filesystem: l38
access::can-read: FALSE
access::can-write: FALSE
access::can-execute: FALSE
access::can-delete: FALSE
access::can-trash: FALSE
access::can-rename: FALSE
time::modified: 1538394987
time::modified-usec: 592109
time::access: 1538395042
time::access-usec: 749090
time::changed: 1538394987
time::changed-usec: 592109
unix::device: 38
unix::inode: 1839867
unix::mode: 17400
unix::nlink: 3
unix::uid: 0
unix::gid: 5000006
unix::rdev: 0
unix::block-size: 32768
unix::blocks: 8
owner::user: root
owner::user-real: root
owner::group: 2de9
2) Next, when I enter the parent /dnfs/shares folder, the two NFS referrals are
mounted. They appear on the Nautilus left panel. This is a strange behaviour
because from terminal the referrals are only mounted when you enter them.
Now gio seems to detect the WRITE access and a new line at the end seems to
show that nautilus have read the NFSv4 acls. Note that the inode is also
updated :
~$ gio test /dnfs/shares/Ressources
nom d'affichage : Ressource
nom d'édition : Ressource
nom : Ressource
type : directory
taille : 4096
uri : file:///dnfs/shares/Ressources
attributs :
standard::type: 2
standard::name: Ressource
standard::display-name: Ressource
standard::edit-name: Ressource
standard::copy-name: Ressource
standard::icon: folder
standard::content-type: inode/directory
standard::fast-content-type: inode/directory
standard::size: 4096
standard::allocated-size: 4096
standard::symbolic-icon: folder-symbolic, folder
etag::value: 1538394987:592109
id::file: l37:23199783
id::filesystem: l37
access::can-read: TRUE
access::can-write: TRUE
access::can-execute: TRUE
access::can-delete: FALSE
access::can-trash: FALSE
access::can-rename: FALSE
time::modified: 1538394987
time::modified-usec: 592109
time::access: 1538395042
time::access-usec: 749090
time::changed: 1538394987
time::changed-usec: 592109
unix::device: 37
unix::inode: 23199783
unix::mode: 17400
unix::nlink: 3
unix::uid: 0
unix::gid: 5000006
unix::rdev: 0
unix::block-size: 32768
unix::blocks: 8
unix::is-mountpoint: TRUE
owner::user: root
owner::user-real: root
owner::group: 2de9
xattr-sys::system.nfs4_acl:
3) From now, the "gio test" result will not change.
Nautilus display crosses on the "Ressources" and "Base" folders as I don't have
the permission to enter them.
But technically I can. And this is disappointing for my teachers users.
4) The real problem come when the teacher want to create a directory inside the
"Ressources" folder. The "New Folder" option stay in grey.
Before the CVE-2017-14604 path. Clicking on the grey option works. But now
nothing is happening. The user can't create the directory.
To workaround the problem there is three possibilies :
-> I can press F5 inside the "Ressource" folder.
-> If I press F5 before entering the "Ressource" folder the crosses disappears
on the referrals. And when I enter the "Ressource" folder I can create
directories inside it.
-> If from any manner I go a second time inside the parent "shares" folder. The
crosses disappears and I can create directories inside the "Ressource" folder.
It's seems that Nautilus rightly handle the permission even with nfs4 ACLs. But
they are not updated on the right time.
Maybe because of the inode change ?
Regards,
Baptiste.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nautilus depends on:
ii desktop-file-utils 0.23-3
ii gsettings-desktop-schemas 3.28.0-1
ii gvfs 1.36.1-1
ii libatk1.0-0 2.28.1-1
ii libc6 2.27-5
ii libcairo-gobject2 1.15.12-1
ii libcairo2 1.15.12-1
ii libexempi3 2.4.5-2
ii libexif12 0.6.21-5
ii libgail-3-0 3.22.30-2
ii libgdk-pixbuf2.0-0 2.36.12-2
ii libglib2.0-0 2.56.1-2
ii libglib2.0-data 2.56.1-2
ii libgnome-autoar-0-0 0.2.3-1
ii libgnome-desktop-3-17 3.28.2-2
ii libgtk-3-0 3.22.30-2
ii libnautilus-extension1a 3.26.3.1-1
ii libpango-1.0-0 1.42.4-1
ii libpangocairo-1.0-0 1.42.4-1
ii libselinux1 2.8-1+b1
ii libtracker-sparql-2.0-0 2.0.3-3
ii libx11-6 2:1.6.6-1
ii nautilus-data 3.26.3.1-1
ii shared-mime-info 1.9-2
Versions of packages nautilus recommends:
ii gnome-sushi 3.28.3-1
ii gvfs-backends 1.36.1-1
ii librsvg2-common 2.40.20-2
Versions of packages nautilus suggests:
ii eog 3.28.3-1
ii evince [pdf-viewer] 3.28.2-1
ii nautilus-extension-brasero 3.12.2-4
ii nautilus-sendto 3.8.6-2
ii totem 3.26.2-1
ii tracker 2.0.3-3
ii xdg-user-dirs 0.17-1
-- no debconf information
More information about the pkg-gnome-maintainers
mailing list