Clarence Donath <[EMAIL PROTECTED]> 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... > > [EMAIL PROTECTED]:/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... > > [EMAIL PROTECTED]:/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, "[EMAIL PROTECTED]"..., 32768) = 486 > write(4, "[EMAIL PROTECTED]"..., 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils