zfs discuss - Jul 2012 - Creating NFSv4/ZFS XATTR through dirfd through /proc not allowed?

Can some one here explain why accessing a NFSv4/ZFS xattr directory
through proc is forbidden?

To explain the problem in shell code (cd -@ is a new option to enter
the XATTR store, redirect {n}<... opens a file or directory and
assigns the fd number to variable ''n''):
ksh -c ''touch x ; cd -@ x ; redirect {n}<"." ; cd .. ;
print "hello"
>/proc/$$/fd/$n/myxattr ; true''
/home/fleyta/bin/ksh: /proc/3982/fd/10/myxattr: cannot create
[Permission denied]

truss says the syscall fails with
open("/proc/3988/fd/10/myxattr", O_WRONLY|O_CREAT|O_TRUNC, 0666)
Err#13 EACCES

Accessing files or directories through /proc/$$/fd/ from a shell
otherwise works, only the xattr directories cause trouble. Native C
code has the same problem.

Olga
-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----''-/`-/     olga.kryzhanovska at gmail.com   \-`\-''----.
 `''-..-| /       http://twitter.com/fleyta     \ |-..-''`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

On Fri, Jul 13, 2012 at 2:16 AM, ????? ????????????
<olga.kryzhanovska at gmail.com> wrote:
> Can some one here explain why accessing a NFSv4/ZFS xattr directory
> through proc is forbidden?
>
[...]
> truss says the syscall fails with
> open("/proc/3988/fd/10/myxattr", O_WRONLY|O_CREAT|O_TRUNC, 0666)
Err#13 EACCES
>
> Accessing files or directories through /proc/$$/fd/ from a shell
> otherwise works, only the xattr directories cause trouble. Native C
> code has the same problem.
>
> Olga
Does "runat" let you see those xattr files?

-- 
Gordon Ross <gwr at nexenta.com>
Nexenta Systems, Inc.  www.nexenta.com
Enterprise class storage for everyone

Yes, accessing the files through runat works.

I think /proc (and /dev/fd, which has the same trouble but only works
if the same process accesses the fds, for obvious reasons since
/dev/fd is per process and can not be shared between processes unlike
/proc/$pid/fd/) gets confused because the directories have no name.
pfiles gets confused in a similar way and some times crashes, but
without a predictable pattern or test case.

As interestingly side note, doing a cd to the /proc/$$/fd/$fd first works:
-------- cut here --------
touch x4 ; cd -@ x4 ; redirect {n}<"." ; cd .. ;
(cd "/proc/$$/fd/$n" ; print "hello1"
>"myxattr") ;
(cd -@ x4 ; cat "myxattr" ) ;
rm x4
-------- stop cutting here --------
Accessing the file with the full path directly does not work:
-------- cut here --------
touch x1 ; cd -@ x1 ; redirect {n}<"." ; cd .. ;
print "hello1" >"/proc/$$/fd/$n/myxattr1" ;
(cd -@ x1 ; cat "myxattr1" ) ;
rm x1
-------- stop cutting here --------

Olga

On Fri, Jul 13, 2012 at 9:17 PM, Gordon Ross <gordon.w.ross at gmail.com>
wrote:
> On Fri, Jul 13, 2012 at 2:16 AM, ????? ????????????
> <olga.kryzhanovska at gmail.com> wrote:
>> Can some one here explain why accessing a NFSv4/ZFS xattr directory
>> through proc is forbidden?
>>
> [...]
>> truss says the syscall fails with
>> open("/proc/3988/fd/10/myxattr", O_WRONLY|O_CREAT|O_TRUNC,
0666) Err#13 EACCES
>>
>> Accessing files or directories through /proc/$$/fd/ from a shell
>> otherwise works, only the xattr directories cause trouble. Native C
>> code has the same problem.
>>
>> Olga
>
> Does "runat" let you see those xattr files?
>
> --
> Gordon Ross <gwr at nexenta.com>
> Nexenta Systems, Inc.  www.nexenta.com
> Enterprise class storage for everyone


-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----''-/`-/     olga.kryzhanovska at gmail.com   \-`\-''----.
 `''-..-| /       http://twitter.com/fleyta     \ |-..-''`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

I don''t think that xattrs were ever intended or designed
for /proc content.

I could file an RFE for you if you wish.

Thanks,

Cindy

On 07/13/12 14:00, ????? ???????????? wrote:
> Yes, accessing the files through runat works.
>
> I think /proc (and /dev/fd, which has the same trouble but only works
> if the same process accesses the fds, for obvious reasons since
> /dev/fd is per process and can not be shared between processes unlike
> /proc/$pid/fd/) gets confused because the directories have no name.
> pfiles gets confused in a similar way and some times crashes, but
> without a predictable pattern or test case.
>
> As interestingly side note, doing a cd to the /proc/$$/fd/$fd first works:
> -------- cut here --------
> touch x4 ; cd -@ x4 ; redirect {n}<"." ; cd .. ;
> (cd "/proc/$$/fd/$n" ; print
"hello1">"myxattr") ;
> (cd -@ x4 ; cat "myxattr" ) ;
> rm x4
> -------- stop cutting here --------
> Accessing the file with the full path directly does not work:
> -------- cut here --------
> touch x1 ; cd -@ x1 ; redirect {n}<"." ; cd .. ;
> print "hello1">"/proc/$$/fd/$n/myxattr1" ;
> (cd -@ x1 ; cat "myxattr1" ) ;
> rm x1
> -------- stop cutting here --------
>
> Olga
>
> On Fri, Jul 13, 2012 at 9:17 PM, Gordon Ross<gordon.w.ross at
gmail.com>  wrote:
>> On Fri, Jul 13, 2012 at 2:16 AM, ????? ????????????
>> <olga.kryzhanovska at gmail.com>  wrote:
>>> Can some one here explain why accessing a NFSv4/ZFS xattr directory
>>> through proc is forbidden?
>>>
>> [...]
>>> truss says the syscall fails with
>>> open("/proc/3988/fd/10/myxattr",
O_WRONLY|O_CREAT|O_TRUNC, 0666) Err#13 EACCES
>>>
>>> Accessing files or directories through /proc/$$/fd/ from a shell
>>> otherwise works, only the xattr directories cause trouble. Native C
>>> code has the same problem.
>>>
>>> Olga
>>
>> Does "runat" let you see those xattr files?
>>
>> --
>> Gordon Ross<gwr at nexenta.com>
>> Nexenta Systems, Inc.  www.nexenta.com
>> Enterprise class storage for everyone
>
>
>

Cindy, I was not trying to open a xattr for files in /proc.
1. Please read the openat() manual page
2. I opened a fd to the directory where the xattrs are in
3. My process, for example pid 123456, now has an open fd, for example
with the number 12, which points to this xattr directory
4. Now I want to use this directory fd to create a file. If I use
openat(12, ...) the code works correct. If I use
open("/proc/123456/fd/12/myxattr",...) the code does NOT work.

IMO this is a bug in the /proc file system, because using the openat()
code path works (to prove that I am not doing some thing impossible).

Olga

On Sat, Jul 14, 2012 at 2:33 AM, Cindy Swearingen
<cindy.swearingen at oracle.com> wrote:
> I don''t think that xattrs were ever intended or designed
> for /proc content.
>
> I could file an RFE for you if you wish.
>
> Thanks,
>
> Cindy
>
>
> On 07/13/12 14:00, ????? ???????????? wrote:
>>
>> Yes, accessing the files through runat works.
>>
>> I think /proc (and /dev/fd, which has the same trouble but only works
>> if the same process accesses the fds, for obvious reasons since
>> /dev/fd is per process and can not be shared between processes unlike
>> /proc/$pid/fd/) gets confused because the directories have no name.
>> pfiles gets confused in a similar way and some times crashes, but
>> without a predictable pattern or test case.
>>
>> As interestingly side note, doing a cd to the /proc/$$/fd/$fd first
works:
>> -------- cut here --------
>> touch x4 ; cd -@ x4 ; redirect {n}<"." ; cd .. ;
>> (cd "/proc/$$/fd/$n" ; print
"hello1">"myxattr") ;
>> (cd -@ x4 ; cat "myxattr" ) ;
>> rm x4
>> -------- stop cutting here --------
>> Accessing the file with the full path directly does not work:
>> -------- cut here --------
>> touch x1 ; cd -@ x1 ; redirect {n}<"." ; cd .. ;
>> print "hello1">"/proc/$$/fd/$n/myxattr1" ;
>> (cd -@ x1 ; cat "myxattr1" ) ;
>> rm x1
>> -------- stop cutting here --------
>>
>> Olga
>>
>> On Fri, Jul 13, 2012 at 9:17 PM, Gordon Ross<gordon.w.ross at
gmail.com>
>> wrote:
>>>
>>> On Fri, Jul 13, 2012 at 2:16 AM, ????? ????????????
>>> <olga.kryzhanovska at gmail.com>  wrote:
>>>>
>>>> Can some one here explain why accessing a NFSv4/ZFS xattr
directory
>>>> through proc is forbidden?
>>>>
>>> [...]
>>>>
>>>> truss says the syscall fails with
>>>> open("/proc/3988/fd/10/myxattr",
O_WRONLY|O_CREAT|O_TRUNC, 0666) Err#13
>>>> EACCES
>>>>
>>>> Accessing files or directories through /proc/$$/fd/ from a
shell
>>>> otherwise works, only the xattr directories cause trouble.
Native C
>>>> code has the same problem.
>>>>
>>>> Olga
>>>
>>>
>>> Does "runat" let you see those xattr files?
>>>
>>> --
>>> Gordon Ross<gwr at nexenta.com>
>>> Nexenta Systems, Inc.  www.nexenta.com
>>> Enterprise class storage for everyone
>>
>>
>>
>>
>


-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----''-/`-/     olga.kryzhanovska at gmail.com   \-`\-''----.
 `''-..-| /       http://twitter.com/fleyta     \ |-..-''`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

On 14 July 2012 02:33, Cindy Swearingen <cindy.swearingen at oracle.com>
wrote:
> I don''t think that xattrs were ever intended or designed
> for /proc content.
>
> I could file an RFE for you if you wish.
So Oracle Newspeak now calls it an RFE if you want a real bug fixed, huh? ;-)

This is a real bug in procfs. Problem is, procfs can''t do name-based
access checking because the directory has no path and comes back with
EACCESS. Same problem can happen with smbfs if the files no longer
exist on the server but the client still has an open filehandle to it
and a different process tries to access it through
/proc/$pid/fd/$fdnum. The advantage of Olga''s testcase is that you
don''t need a tricky smbfs/samba setup to reproduce.

Ced
-- 
Cedric Blancher <cedric.blancher at googlemail.com>
Institute Pasteur

I speak for myself... :-)

If the real bug is in procfs, I can file a CR.

When xattrs were designed right down the hall from me,
I don''t think /proc interactions were considered, which
is why I mentioned an RFE.

Thanks,

Cindy




On 07/15/12 15:59, Cedric Blancher wrote:
> On 14 July 2012 02:33, Cindy Swearingen<cindy.swearingen at
oracle.com>  wrote:
>> I don''t think that xattrs were ever intended or designed
>> for /proc content.
>>
>> I could file an RFE for you if you wish.
>
> So Oracle Newspeak now calls it an RFE if you want a real bug fixed, huh?
;-)
>
> This is a real bug in procfs. Problem is, procfs can''t do
name-based
> access checking because the directory has no path and comes back with
> EACCESS. Same problem can happen with smbfs if the files no longer
> exist on the server but the client still has an open filehandle to it
> and a different process tries to access it through
> /proc/$pid/fd/$fdnum. The advantage of Olga''s testcase is that you
> don''t need a tricky smbfs/samba setup to reproduce.
>
> Ced