Bug 972294 - lsetxattr/lgetxattr doesn't work to softlink file with ntfs FS in rhel7
lsetxattr/lgetxattr doesn't work to softlink file with ntfs FS in rhel7
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-08 03:58 EDT by bfan
Modified: 2014-04-25 05:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-25 05:22:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bfan 2013-06-08 03:58:58 EDT
Description of problem:
lgetxattr can't read the attribute of a softlink file with ntfs FS, shows "lgetxattr: No data available". on one hand, it's lgetxattr issue, on other hand, may lsetxattr doesn't work to softlink


Version-Release number of selected component (if applicable):
libguestfs-1.22.2-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
# guestfish -N fs:ntfs

Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

><fs> trace 1
><fs> mount-options user_xattr /dev/sda1 /
libguestfs: trace: mount_options "user_xattr" "/dev/sda1" "/"
libguestfs: trace: mount_options = 0
><fs> touch /test.txt
libguestfs: trace: touch "/test.txt"
libguestfs: trace: touch = 0
><fs> ln-s /test.txt /link.txt
libguestfs: trace: ln_s "/test.txt" "/link.txt"
libguestfs: trace: ln_s = 0
><fs> ll /
libguestfs: trace: ll "/"
libguestfs: trace: ll = "total 9\ndrwxrwxrwx  1 root root 4096 Jun  8 10:58 .\ndrwxr-xr-x 23 root root 4096 Jun  8 10:57 ..\nlrwxrwxrwx  1 root root   26 Jun  8 10:58 link.txt -> /test.txt\n-rwxrwxrwx  1 root root    0 Jun  8 10:57 test.txt\n"
total 9
drwxrwxrwx  1 root root 4096 Jun  8 10:58 .
drwxr-xr-x 23 root root 4096 Jun  8 10:57 ..
lrwxrwxrwx  1 root root   26 Jun  8 10:58 link.txt -> /test.txt
-rwxrwxrwx  1 root root    0 Jun  8 10:57 test.txt
><fs> lsetxattr security.name "hello" 5 /link.txt
libguestfs: trace: lsetxattr "security.name" "hello" 5 "/link.txt"
libguestfs: trace: lsetxattr = 0
><fs> lsetxattr security.type "ascii file" 10 /link.txt
libguestfs: trace: lsetxattr "security.type" "ascii file" 10 "/link.txt"
libguestfs: trace: lsetxattr = 0
><fs> lgetxattr /link.txt security.name
libguestfs: trace: lgetxattr "/link.txt" "security.name"
libguestfs: trace: lgetxattr = NULL (error)
libguestfs: error: lgetxattr: lgetxattr: No data available
><fs>



Actual results:
lgetxattr read a specified attribute failed


Expected results:
lgetxattrs can work well


Additional info:
1. It works well with ext FS
2. regression, works with libguestfs-1.20.2-1.el7.x86_64
Comment 2 Richard W.M. Jones 2013-06-10 11:27:30 EDT
I'm fairly dubious that:

><fs> lsetxattr security.name "hello" 5 /link.txt

should work at all.  Note *l*setxattr should set the attribute
on the symbolic link, not on the target file.  But does it make
sense to set security.* attributes on the symbolic link?  I
guess the answer depends on details of ntfs-3g or even of the
NTFS file format itself.
Comment 3 Richard W.M. Jones 2013-07-18 18:19:41 EDT
Using user.* attributes instead of security.* attributes
(see https://bugzilla.redhat.com/show_bug.cgi?id=972292#c2)
I get the following error:

$ guestfish -N fs:ntfs -m /dev/sda1:/:user_xattr touch /test.txt : ln-s /test.txt /link.txt : lsetxattr user.name "hello" 5 /link.txt : lsetxattr user.type "ascii file" 10 /link.txt : lgetxattr /link.txt user.name : echo : lgetxattrs /link.txt
libguestfs: error: lsetxattr: setxattr: Operation not permitted

So it seems that ntfs-3g is not happy with us setting xattrs
on symbolic links (although this is possible for ordinary
Unix-like filesystems).

Things work through the symlink if you use setxattr/getxattr
instead:

$ guestfish -N fs:ntfs -m /dev/sda1:/:user_xattr touch /test.txt : ln-s /test.txt /link.txt : setxattr user.name "hello" 5 /link.txt : setxattr user.type "ascii file" 10 /link.txt : getxattr /link.txt user.name : echo : getxattrs /link.txt
hello
[0] = {
  attrname: user.name
  attrval: hello
}
[1] = {
  attrname: user.type
  attrval: ascii file
}

I'm not sure what to conclude about this, except that NTFS
is a strange not-Unix-like filesystem, and ntfs-3g works
through FUSE so everything's complicated.

Probably not something we need to worry about.
Comment 5 Richard W.M. Jones 2014-04-25 05:22:58 EDT
I don't think this is something we care about.  As I said
in comment 3, ntfs is a non-Unix filesystem, and ntfs-3g works
via FUSE which complicates things.  In addition ntfs has its
own way of doing symbolic links (using a strange binary format).

Note You need to log in before you can comment on or make changes to this bug.