A bug in the vfs_gpfs.c module

Richard Sharpe realrichardsharpe at gmail.com
Sun May 1 12:38:22 MDT 2011

On Sat, Apr 30, 2011 at 3:21 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi,
> I was tracking down a weird problem with the GPFS VFS module where I
> currently work. The problem manifested itself in the following way:
> 1. User 1 creates a word file on a GPFS-hosted share. The ACL ends up
> a little funky, with a funny special:owner@ ACE that seems to be
> inherited from the parent dir. There is also a special:group@ ACE that
> gives Domain Users all access, it seems.
> 2. User 2 edits the same word file and saves it. The ACL changes so
> that now the first ACE is no longer special, but is user:User 1: same
> permissions as owner@ had above [1]. Then there is the special:group@
> ACE as before. The upshot is that User 2 now owns the file but only
> has access via the group ACE and the UNIX permissions look like
> ----rwxr-x.
> 3. User 2 does some more edits and tries to save the file. This time
> around the save fails and User 2 is told that the file is READ ONLY or
> in some cases PERMISSION DENIED (I think I have seen both).
> After some investigation, and setting 'store dos attributes = yes' in
> the smb.conf I found that there is a problem in the vfs_gpfs.c module
> in the following way. When smbd/dosmode.c:dos_mode is called (perhaps
> as a result of QPATHINFO):
> 1. in smbd/dosmode.c:get_ea_dos_attribute we find that it expects that
> SMB_VFS_GETXATTR will return a blob that it then parses with
> ndr_pull_struct_blob.
> 2. However, in modules/vfs_gpfs.c:gpfs_get_attr it uses the
> compatibility mode for these things and tries to return
>   a hex code:
>        snprintf(attrstr, size, "0x%x", dosmode & SAMBA_ATTRIBUTES_MASK);
>        DEBUG(10, ("gpfs_get_xattr: returning %s\n",attrstr));
>        return size;
>    Unfortunately, it seems now to create the incorrect info, since I
> then see the following DEBUG info in the log file:
>    DEBUG(1,("get_ea_dos_attributes: Badly formed DOSATTRIB on " ...);
> which results in get_ea_dos_attribute failing and so,
> smbd/dosmode.c:dos_mode, it falls back to dos_mode_from_sbuf, which
> uses the UNIX permissions for the file, however, the UNIX permissions
> are synthesized and in at least the case seen above, the owner of the
> file does not have W permission, so Windows gets told that the file is
> READONLY even though the ACL on the file would allow the owner access
> via the group ACE.
> I am still trying to understand whether or not things changed such
> that the vfs_gpfs.c module is no longer returning the correct data, or
> what. Any help would be appreciated.

OK, it seems that there is a bug in the vfs_gpfs.c:gpfs_get_xattr
function. It returns size, which is the size of the string passed in,
but in order to prevent ndr_pull_struct_blob from going off the rails
(actually, ndr_pull_xattr_DOSATTRIB) it should return strlen(attrstr).

I will prepare a fix and test it on Monday and if that is successful I
will post it.

Here is the log file info I am currently seeing:

[2011/04/29 22:01:22.259716, 10]
modules/vfs_gpfs.c:957(gpfs_get_xattr)  gpfs_get_xattr: ./A test
document 1.docx
[2011/04/29 22:01:22.259724, 10] modules/gpfs.c:163(get_gpfs_winattrs)
  gpfs_get_winattrs_path:open call ./A test document 1.docx
[2011/04/29 22:01:22.259740, 10] modules/vfs_gpfs.c:971(gpfs_get_xattr)
  gpfs_get_xattr:Got attributes: 0x1[2011/04/29 22:01:22.259750, 10]
  gpfs_get_xattr: returning 0x20
[2011/04/29 22:01:22.259761,  1] ../librpc/ndr/ndr.c:395(ndr_pull_error)
  ndr_pull_error(2): Bad switch value 35744 for r at ../librpc/gen_ndr/ndr_xattr
[2011/04/29 22:01:22.259770, 10] smbd/dosmode.c:268(get_ea_dos_attribute)
  get_ea_dos_attribute: ./A test document 1.docx attr =
0x20[2011/04/29 22:01:22.259778,  1]
  get_ea_dos_attributes: Badly formed DOSATTRIB on file ./A test document 1.docx
 - 0x20[2011/04/29 22:01:22.259785,  8]
smbd/dosmode.c:207(dos_mode_from_sbuf)  dos_mode_from_sbuf returning a
[2011/04/29 22:01:22.259793,  8] smbd/dosmode.c:666(dos_mode)
  dos_mode returning a[sparse]

Richard Sharpe

More information about the samba-technical mailing list