All of lore.kernel.org
 help / color / mirror / Atom feed
* fsetxattr(2) for ACL on nfs
@ 2017-05-25 22:37 J. R. Okajima
  2017-05-26 19:58 ` Andreas Dilger
  0 siblings, 1 reply; 4+ messages in thread
From: J. R. Okajima @ 2017-05-25 22:37 UTC (permalink / raw)
  To: linux-nfs; +Cc: linux-fsdevel

Since v4.12-rc1, I see an error on NFS3.

$ stat -f .
  File: "."
    ID: 0        Namelen: 255     Type: nfs
Block size: 32768      Fundamental block size: 32768
Blocks: Total: 248        Free: 247        Available: 234
Inodes: Total: 2048       Free: 2020
$ cp ../ro/f_src .
$ rm f_src
rm: remove regular file 'f_src'? y
$ cp -p ../ro/f_src .
cp: preserving permissions for './f_src': Permission denied

(from "cp --help")
  -p                           same as --preserve=mode,ownership,timestamps
      --preserve[=ATTR_LIST]   preserve the specified attributes (default:
                                 mode,ownership,timestamps), if possible
                                 additional attributes: context, links, xattr,
                                 all

By strace, I see fsetxattr(2) for ACL returned the error.
Is this an intentional behaviour?

(from strace)
open("../ro/f_src", O_RDONLY)           = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcb293f8000
read(3, "f\n", 131072)                  = 2
write(4, "f\n", 2)                      = 2
read(3, "", 131072)                     = 0
utimensat(4, NULL, {{1495750885, 0}, {1495750885, 0}}, 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7ffed40196d0, 132) = -1 ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EACCES (Permission denied)
fchmod(4, 0100644)                      = 0
open("/usr/lib/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)
write(2, "cp: ", 4)                     = 4
write(2, "preserving permissions for './f_"..., 36) = 36
write(2, ": Permission denied", 19)     = 19
write(2, "\n", 1)                       = 1

Additonally, after this error, the shutdown process stops saying
	nfs: server localhost not responding, still trying

Does anyone know which commit causes these problems?


J. R. Okajima

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fsetxattr(2) for ACL on nfs
  2017-05-25 22:37 fsetxattr(2) for ACL on nfs J. R. Okajima
@ 2017-05-26 19:58 ` Andreas Dilger
  2017-05-26 23:59   ` J. R. Okajima
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Dilger @ 2017-05-26 19:58 UTC (permalink / raw)
  To: J. R. Okajima; +Cc: Linux NFS Mailing List, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

On May 25, 2017, at 4:37 PM, J. R. Okajima <hooanon05g@gmail.com> wrote:
> 
> Since v4.12-rc1, I see an error on NFS3.
> 
> $ stat -f .
>  File: "."
>    ID: 0        Namelen: 255     Type: nfs
> Block size: 32768      Fundamental block size: 32768
> Blocks: Total: 248        Free: 247        Available: 234
> Inodes: Total: 2048       Free: 2020
> $ cp ../ro/f_src .
> $ rm f_src
> rm: remove regular file 'f_src'? y
> $ cp -p ../ro/f_src .
> cp: preserving permissions for './f_src': Permission denied
> 
> (from "cp --help")
>  -p                           same as --preserve=mode,ownership,timestamps
>      --preserve[=ATTR_LIST]   preserve the specified attributes (default:
>                                 mode,ownership,timestamps), if possible
>                                 additional attributes: context, links, xattr,
>                                 all
> 
> By strace, I see fsetxattr(2) for ACL returned the error.
> Is this an intentional behaviour?
> 
> (from strace)
> open("../ro/f_src", O_RDONLY)           = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
> fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcb293f8000
> read(3, "f\n", 131072)                  = 2
> write(4, "f\n", 2)                      = 2
> read(3, "", 131072)                     = 0
> utimensat(4, NULL, {{1495750885, 0}, {1495750885, 0}}, 0) = 0
> fgetxattr(3, "system.posix_acl_access", 0x7ffed40196d0, 132) = -1 ENODATA (No data available)
> fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EACCES (Permission denied)

To me this looks like "cp" is broken.  If it gets no POSIX ACL xattr from the
kernel (ENODATA) for this file, why is it trying to save a POSIX ACL to the
copy?  That just adds needless overhead, either at the syscall level, or also
on disk if it is storing ACLs on files that don't need them...

Cheers, Andreas

> fchmod(4, 0100644)                      = 0
> open("/usr/lib/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)
> write(2, "cp: ", 4)                     = 4
> write(2, "preserving permissions for './f_"..., 36) = 36
> write(2, ": Permission denied", 19)     = 19
> write(2, "\n", 1)                       = 1
> 
> Additonally, after this error, the shutdown process stops saying
> 	nfs: server localhost not responding, still trying
> 
> Does anyone know which commit causes these problems?
> 
> 
> J. R. Okajima


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fsetxattr(2) for ACL on nfs
  2017-05-26 19:58 ` Andreas Dilger
@ 2017-05-26 23:59   ` J. R. Okajima
  2017-05-31 20:32     ` J. Bruce Fields
  0 siblings, 1 reply; 4+ messages in thread
From: J. R. Okajima @ 2017-05-26 23:59 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: Linux NFS Mailing List, linux-fsdevel

Andreas Dilger:
> > open("../ro/f_src", O_RDONLY)           = 3
> > fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> > open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
> > fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> > fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> > mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcb293f8000
> > read(3, "f\n", 131072)                  = 2
> > write(4, "f\n", 2)                      = 2
> > read(3, "", 131072)                     = 0
> > utimensat(4, NULL, {{1495750885, 0}, {1495750885, 0}}, 0) = 0
> > fgetxattr(3, "system.posix_acl_access", 0x7ffed40196d0, 132) = -1 ENODATA (No data available)
> > fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> > fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EACCES (Permission denied)
>
> To me this looks like "cp" is broken.  If it gets no POSIX ACL xattr from the
> kernel (ENODATA) for this file, why is it trying to save a POSIX ACL to the
> copy?  That just adds needless overhead, either at the syscall level, or also
> on disk if it is storing ACLs on files that don't need them...

Maybe you are right.
But on v4.11, it succeeded.

open("../ro/f_src", O_RDONLY)           = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3dcf031000
read(3, "f\n", 131072)                  = 2
write(4, "f\n", 2)                      = 2
read(3, "", 131072)                     = 0
utimensat(4, NULL, {{1495842847, 0}, {1495842847, 0}}, 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7fff63443360, 132) = -1 ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0


J. R. Okajima

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: fsetxattr(2) for ACL on nfs
  2017-05-26 23:59   ` J. R. Okajima
@ 2017-05-31 20:32     ` J. Bruce Fields
  0 siblings, 0 replies; 4+ messages in thread
From: J. Bruce Fields @ 2017-05-31 20:32 UTC (permalink / raw)
  To: J. R. Okajima; +Cc: Andreas Dilger, Linux NFS Mailing List, linux-fsdevel

It's a known bug, I've been slow to get it upstream, apologies, I'll try
to get it in for -rc4.

--b.

On Sat, May 27, 2017 at 08:59:56AM +0900, J. R. Okajima wrote:
> Andreas Dilger:
> > > open("../ro/f_src", O_RDONLY)           = 3
> > > fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> > > open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
> > > fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> > > fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> > > mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcb293f8000
> > > read(3, "f\n", 131072)                  = 2
> > > write(4, "f\n", 2)                      = 2
> > > read(3, "", 131072)                     = 0
> > > utimensat(4, NULL, {{1495750885, 0}, {1495750885, 0}}, 0) = 0
> > > fgetxattr(3, "system.posix_acl_access", 0x7ffed40196d0, 132) = -1 ENODATA (No data available)
> > > fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> > > fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EACCES (Permission denied)
> >
> > To me this looks like "cp" is broken.  If it gets no POSIX ACL xattr from the
> > kernel (ENODATA) for this file, why is it trying to save a POSIX ACL to the
> > copy?  That just adds needless overhead, either at the syscall level, or also
> > on disk if it is storing ACLs on files that don't need them...
> 
> Maybe you are right.
> But on v4.11, it succeeded.
> 
> open("../ro/f_src", O_RDONLY)           = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> open("./f_src", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
> fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3dcf031000
> read(3, "f\n", 131072)                  = 2
> write(4, "f\n", 2)                      = 2
> read(3, "", 131072)                     = 0
> utimensat(4, NULL, {{1495842847, 0}, {1495842847, 0}}, 0) = 0
> fgetxattr(3, "system.posix_acl_access", 0x7fff63443360, 132) = -1 ENODATA (No data available)
> fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0
> 
> 
> J. R. Okajima
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-05-31 20:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-25 22:37 fsetxattr(2) for ACL on nfs J. R. Okajima
2017-05-26 19:58 ` Andreas Dilger
2017-05-26 23:59   ` J. R. Okajima
2017-05-31 20:32     ` J. Bruce Fields

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.