Re: cp failure to NetApp directory with CIFS security model

[Jim Meyering]

Clarence Donath <address@hidden> wrote:
...
> This destination location is certainly not fully POSIX compliant.  It's
> a method NetApp has developed to allow UNIX user access to be controlled
> by Windows ACLs.
>
> Using the recent snapshot exhibits the same behavior.
>
> Running strace using cp v6.9-354-68c33a produces the following...
>
> address@hidden:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet
> [snip]
> stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
> stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
> stat64("/p/inet/cron", 0xbfb66bf4)      = -1 ENOENT (No such file or
> directory)
> open("/root/cron", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
> open("/p/inet/cron", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1
> EPERM (Operation not permitted)

As you have guessed,
the problem seems to be the addition of the O_EXCL flag.
Earlier versions (including 6.6, below) of GNU cp didn't use O_EXCL,
and as such, were sometimes vulnerable to a symlink attack.

It looks like this is unrelated to permissions, in spite of the EPERM
failure.  Rather, it may be that your server system mishandles the
O_CREAT|O_EXCL combination.  That's supposed to make the open syscall
fail with EEXIST if the destination already exists.
Besides, if there's really an open _failure_ due to permissions,
it shouldn't it create the file at all.

...
> The resultant destination file is created, but left empty by 'cp'.
> A second 'cp' will succeed since the file was created by the first 'cp'.

Right, since it no longer tries to use the O_EXCL flag
when the destination file exists.

> Running strace using cp v6.6 successfully copies the file, and produces
> the following...
>
> address@hidden:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet
> [snip]
> stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
> stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
> stat64("/p/inet/cron", 0xbf8e5954)      = -1 ENOENT (No such file or
> directory)
> open("/root/cron", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
> open("/p/inet/cron", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 4
> fstat64(4, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
> read(3, "address@hidden"..., 32768) = 486
> write(4, "address@hidden"..., 486) = 486
> close(4)                                = 0
> close(3)                                = 0
> close(1)                                = 0
> close(2)                                = 0
> exit_group(0)                           = ?
>
> The new open() call causes cp to terminate.  Is it the O_EXCL causing
> this?

I suspect it's a bug in the file system code.

> What concerns me is the following from the open() man page...
>
>         O_EXCL is broken on  NFS  file  systems; programs which rely on
> it for performing
>         locking tasks will contain a race condition.

Some people use the atomicity of O_CREAT|O_EXCL to implement
locks.  That's just warning you that while it works fine on a
local file system, it will not work on an NFS-mounted file system.