Re: BUG on permission check with ACLs : possible to disable it ?
Nelson Benítez León via nautilus-list <[email protected]> Mon, 8 Oct 2018 07:52:30 +0200
| Newsgroups | gmane.comp.gnome.nautilus |
|---|---|
| Message-ID | <CAAUd6417hQFUw3MCPo1NxtB1OqqXS_2nQzZHzsfknhW=0x9ZBA@mail.gmail.com> |
--===============3316167881305808230== Content-Type: multipart/alternative; boundary="00000000000036fb780577b13cb7" --00000000000036fb780577b13cb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your bug may have coincidences with https://bugzilla.gnome.org/show_bug.cgi?id=3D703179 especially check my comment 14, in that bug's case inotify fires two consecutive events for a new mountpoint, the first carries wrong info and the second the correct info, but nautilus wrongly discard the second one as it's still processing the first one. The patch was not merged so if you want to try it you may need to rebase it= . El lun., 1 oct. 2018 a las 15:02, Prunk Dump via nautilus-list (< [email protected]>) escribi=C3=B3: > Hello Gnome Nautilus Team ! > > I'm a high school network administrator and I'm face to a new bug > since an update of nautilus in Debian Stretch. Maybe you can help me > to correct it or to find a workaround. > > The simple explanation : > ------------------------------------ > > I export the users files using an NFSv4 server. Some directories have > some specific ACLs that are not displayed on the client side. This is > normal. Actually the ACLs are not displayed through NFS. For example > on the client : > > # ls -al /dnfs/shares/teachers/class1 > drwxrwx--T 3 root class1 4096 oct. 1 13:56 Ressource > > This folder have a special ACL that let RWX access to the "teachers" > group. But we can't see it on the clients. The is no "+" on the result > of the ls command. > > So Nautilus show a cross on the folder. But the teacher can enter > inside it. So this is not a big problem. Just a little disappointing > for the teacher. > > The real problem come when the teacher want to create a directory > inside it. This time the "New directory" choice is Grey. The teacher > can't click on it. > > Si is there a way to disable the permission check on Nautilus ? > > The more in depth explanation : > --------------------------------------------- > > The bug is more complex in reality. I use NFSv4 referrals on my > network. This mean that when the user enter the folder : > > /dnfs/shares/teachers/class1 > > This create a mount point over "/dnfs/shares/teachers/class1". And the > mount point appear on the Nautilus left panel. > > The teacher can't create directories inside it. > > But if the user traverse the directories again. Starting from "/dnfs" > to "/dnfs/shares/teachers/class1" now it can create directories !!! > > It just don't works the first time. The user need to enter the > "class1" folder a second time. > > So I don't know how nautilus check permissions. Because this time > there is still no information on the client side about the teacher's > ACL. But in this case the Nautilus "New folder" is not Grey. And the > user can create directories. I can't understand why Nautilus decide to > active the "New Folder" choice this time. > > Before the update. The "New folder" was still Grey. But if the teacher > click on it the directory was created anyway. > > An idea from where come this bug ? > > Regards, > > Baptiste. > -- > nautilus-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/nautilus-list > --00000000000036fb780577b13cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Your bug may have coincidences with <a hr= ef=3D"https://bugzilla.gnome.org/show_bug.cgi?id=3D703179">https://bugzilla= .gnome.org/show_bug.cgi?id=3D703179</a> especially check my comment 14, in = that bug's case inotify fires two consecutive events for a new mountpoi= nt, the first carries wrong info and the second the correct info, but nauti= lus wrongly discard the second one as it's still processing the first o= ne.=C2=A0</div><div dir=3D"ltr"><br></div><div>The patch was not merged so = if you want to try it you may need to rebase it.</div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr">El lun., 1 oct. 2018 a las 15:02, Prunk D= ump via nautilus-list (<<a href=3D"mailto:[email protected]">nauti= [email protected]</a>>) escribi=C3=B3:<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex">Hello Gnome Nautilus Team !<br> <br> I'm a high school network administrator and I'm face to a new bug<b= r> since an update of nautilus in Debian Stretch. Maybe you can help me<br> to correct it or to find a workaround.<br> <br> The simple explanation :<br> ------------------------------------<br> <br> I export the users files using an NFSv4 server. Some directories have<br> some specific ACLs that are not displayed on the client side. This is<br> normal. Actually the ACLs are not displayed through NFS. For example<br> on the client :<br> <br> # ls -al /dnfs/shares/teachers/class1<br> drwxrwx--T=C2=A0 3 root class1 4096 oct.=C2=A0 =C2=A01 13:56 Ressource<br> <br> This folder have a special ACL that let RWX access to the "teachers&qu= ot;<br> group. But we can't see it on the clients. The is no "+" on t= he result<br> of the ls command.<br> <br> So Nautilus show a cross on the folder. But the teacher can enter<br> inside it. So this is not a big problem. Just a little disappointing<br> for the teacher.<br> <br> The real problem come when the teacher want to create a directory<br> inside it. This time the "New directory" choice is Grey. The teac= her<br> can't click on it.<br> <br> Si is there a way to disable the permission check on Nautilus ?<br> <br> The more in depth explanation :<br> ---------------------------------------------<br> <br> The bug is more complex in reality. I use NFSv4 referrals on my<br> network. This mean that when the user enter the folder :<br> <br> /dnfs/shares/teachers/class1<br> <br> This create a mount point over "/dnfs/shares/teachers/class1". An= d the<br> mount point appear on the Nautilus left panel.<br> <br> The teacher can't create directories inside it.<br> <br> But if the user traverse the directories again. Starting from "/dnfs&q= uot;<br> to "/dnfs/shares/teachers/class1" now it can create directories != !!<br> <br> It just don't works the first time. The user need to enter the<br> "class1" folder a second time.<br> <br> So I don't know how nautilus check permissions. Because this time<br> there is still no information on the client side about the teacher's<br= > ACL. But in this case the Nautilus "New folder" is not Grey. And = the<br> user can create directories. I can't understand why Nautilus decide to<= br> active the "New Folder" choice this time.<br> <br> Before the update. The "New folder" was still Grey. But if the te= acher<br> click on it the directory was created anyway.<br> <br> An idea from where come this bug ?<br> <br> Regards,<br> <br> Baptiste.<br> -- <br> nautilus-list mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">nautilus-list@= gnome.org</a><br> <a href=3D"https://mail.gnome.org/mailman/listinfo/nautilus-list" rel=3D"no= referrer" target=3D"_blank">https://mail.gnome.org/mailman/listinfo/nautilu= s-list</a><br> </blockquote></div> --00000000000036fb780577b13cb7-- --===============3316167881305808230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- nautilus-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/nautilus-list --===============3316167881305808230==--