bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cp failure to NetApp directory with CIFS security model


From: Clarence Donath
Subject: cp failure to NetApp directory with CIFS security model
Date: Wed, 31 Oct 2007 10:44:44 -0400

We are experiencing undesired behavior using 'cp' and its siblings
involving a NetApp filer qtree with the CIFS security model.

The CIFS security model on this type of system, or at least in our
environment, allows Windows ACLs to control the permissions of
directories/files.  UNIX accounts map to AD accounts, so UNIX users can
have varying permissions controlled by the Windows ACLs.

Files in these areas look like this in UNIX,
-rwxrwxrwx 1 username  group     9 2007-10-31 10:24 file

'username' doesn't necessarily have 'rwx' to the file.  It depends on
what Windows ACLs are set.


UNIX functions like chmod will fail, because changing of the permission
bits is not allowed by the filer.

This has not been a problem for everyday use by users who understand
this security model we have implemented, but now we see new behavior
with the plain-jane 'cp' command.

The problem appears to be that 'cp' is trying to change the permissions
on a new destination file before it copies over the contents of the
file.

/bin/cp file file2
/bin/cp: cannot create regular file `file2': Operation not permitted

This creates the file, but does not transfer the contents...

-rwxrwxrwx 1 username  group     9 2007-10-31 10:32 file
-rwxrwxrwx 1 username  group     0 2007-10-31 10:32 file2

Performing another 'cp' will then successfully transfer the contents...

-rwxrwxrwx 1 username  group     9 2007-10-31 10:32 file
-rwxrwxrwx 1 username  group     9 2007-10-31 10:32 file2


What I assume is happening here is that 'cp' is trying to change the
permissons of the file after it opens a new one for writing, and
terminates when it cannot do so.

This behavior occurs with coreutils versions 6.7 and 6.9, but not
previous versions.

It may be that the previous versions also tried to set permissions on a
new file, but at least it didn't die when it couldn't do so.

Before I start to investigate what has changed or develop a patch, I'm
wondering if any developers know off-hand why the design in this area
was changed, and if we have any hope of returning to previous behavior
to support our use of our NetApp filer.


Best Regards,
Clarence Donath





reply via email to

[Prev in Thread] Current Thread [Next in Thread]