Re: BUG on permission check with ACLs : possible to disable it ?
António Fernandes via nautilus-list <[email protected]> Mon, 1 Oct 2018 14:46:36 +0100
| Newsgroups | gmane.comp.gnome.nautilus |
|---|---|
| Message-ID | <CAJa6Smd0uOh9wqP72hQzKdD0OmRd8tZ_xUKKXEFh=kvY02ypHw@mail.gmail.com> |
--===============5573188250523804185== Content-Type: multipart/alternative; boundary="00000000000061f5f505772b09e4" --00000000000061f5f505772b09e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. Since this sounds like a bug, can you file it at our issue tracker as well? https://gitlab.gnome.org/GNOME/nautilus/issues/new?issuable_template=3DBug You can check what the following command reports the first time, and if there is any change after that: gio info /dnfs/shares/teachers/class1 In particular, look for the "access::can-write" attribute and confirm if it says "TRUE" or "FALSE". > But if the user traverse the directories again. Starting from "/dnfs" > to "/dnfs/shares/teachers/class1" now it can create directories !!! Does it also work if the user refreshes the view (pressing [F5])? Or is traversing the directory starting from /dnfs a requirement? Prunk Dump via nautilus-list <[email protected]> escreveu no dia segunda, 1/10/2018 =C3=A0s 14:02: > 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 > --00000000000061f5f505772b09e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello.<br><br>Since this sounds like a bug, can you file i= t at our issue tracker as well?=C2=A0<a href=3D"https://gitlab.gnome.org/GN= OME/nautilus/issues/new?issuable_template=3DBug">https://gitlab.gnome.org/G= NOME/nautilus/issues/new?issuable_template=3DBug</a><br><br>You can check w= hat the following command reports=C2=A0<span style=3D"color:rgb(33,33,33)">= the first time, and if there is any change after that:<br></span><br>gio in= fo=C2=A0<span style=3D"color:rgb(33,33,33)">/dnfs/shares/teachers/class1</s= pan><br><br>In particular, look for the "access::can-write" attri= bute and confirm if it says "TRUE" or "FALSE".<br><br><= span style=3D"color:rgb(33,33,33)">> But if the user traverse the direct= ories again. Starting from "/dnfs"</span><br style=3D"color:rgb(3= 3,33,33)"><span style=3D"color:rgb(33,33,33)">> to "/dnfs/shares/te= achers/class1" now it can create directories !!!<br></span><br>Does it= also work if the user refreshes the view (pressing [F5])? Or is traversing= the directory starting from /dnfs a requirement?<br></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr">Prunk Dump via nautilus-list <<a href= =3D"mailto:[email protected]">[email protected]</a>> escreve= u no dia segunda, 1/10/2018 =C3=A0s 14:02:<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> --00000000000061f5f505772b09e4-- --===============5573188250523804185== 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 --===============5573188250523804185==--