Re: cp -p error when directory security is modified from Windows

[Bob Proulx]

Greg Aloe wrote:
> > Okay.  (Is SunOS an NFS fileserver in your example?  You did not say
> > but I am guessing that is true.)
> 
> I used the same directory (/home/galoe/trash/testdir) for each of my
> tests on i686, x86_64, and Solaris.  So it is the same fileserver.  The
> fileserver's file system is NTFS.

Hmm...  Does NTFS support UNIX permissions, user, group, other?  I did
not think so.  In which case the emulation layer between NTFS and the
unix filesystem will have to make up something to fill in the gaps.
In general compromises will have to be made in that case and you just
can't expect to have full functionality if the underlying filesystem
does not support all of the same functionality.

> > Your word wrapping here is unfortunate and makes the examples hard to
> > follow.  In the future if you could make your examples verbatim it
> > would be easier to read.  I needed to do a lot of trimming and
> > *imagining* what it must have looked like to you.
>  
> I sent my email in HTML format which should not have wrapped the text.
> I apologize that I didn't account for plain text viewers, but the
> commands are simple, so there shouldn't be any ambiguous possibilities.

HTML email is a controversial subject.  Generally it is better to
avoid it on the technical lists as it is not appreciated by many on
the 'net.

> No, there are no problems to this point.  I'm simply trying to show how
> things should look when I haven't yet touched the Windows security
> settings.  The possible bug starts at this point forward.

Okay.  But if the problem is ms-windows security settings then you are
doubly stuck.

> It is possible that the problem is caused by Windows, but why does the
> problem persist if the permissions of the directory haven't changed?
> I'd like to reiterate that I didn't make any actual changes to the
> Windows security settings.  I toggled a checkbox with no changes, and
> clicked "Apply".

I have no idea.  I try not to meddle in the affairs of NTFS, for it is
subtle and quick to anger.  And because I don't have an NTFS system of
any type.  So it is necessary for others to debug this.

> > >       [hostname:/home/galoe/trash]134 % cp -p
> > > /devel/A/nightly/matlabinternetfile.txt testdir/
> > >
> > >       cp: setting permissions for `testdir/matlabinternetfile.txt':
> > > Operation not permitted

Try running strace on the cp binary and saving the output.  Then we
can look at the system calls that cp is calling and the return values
from them.
  
  strace -e trace=file -o /tmp/strace.out cp -p 
/devel/A/nightly/matlabinternetfile.txt testdir/
  grep matlabinternetfile /tmp/strace.out

What output do you get?

When I do this on my machine with the following files (and so happens
I get the following output.

  touch file1
  mkdir a
  strace -e trace=file -o /tmp/strace.out cp -p file1 file2
  grep file1  /tmp/strace.out 

  execve("/bin/cp", ["cp", "-p", "file1", "a/"], [/* 24 vars */]) = 0
  stat64("file1", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
  stat64("a/file1", 0xbffff8c0)           = -1 ENOENT (No such file or 
directory)
  open("file1", O_RDONLY|O_LARGEFILE)     = 3
  open("a/file1", O_WRONLY|O_CREAT|O_LARGEFILE, 0100664) = 4
  utimes("a/file1", {1122611690, 0})      = -1 ENOSYS (Function not implemented)
  utime("a/file1", [2005/07/28-22:34:50, 2005/07/28-22:34:45]) = 0
  chown32("a/file1", 1000, 1000)          = 0
  getxattr("file1", "system.posix_acl_access", 0xbffff630, 132) = -1 EOPNOTSUPP 
(Operation not supported)
  setxattr("a/file1", "system.posix_acl_access", 
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff
 \x00\x04\x00\xff\xff\xff\xff", 28, ) = -1 EOPNOTSUPP (Operation not supported)
  chmod("a/file1", 0100664)               = 0

> > Apparently you are running a security policy on that filesystem which
> > is different from the modern norm.  Normally you would not have had
> > permission to change the ownership of that file to user "batserve"
> > because you are not that user.  But because it did allow you to change
> > the ownership then it no longer allowed you to change the permissions
> > because you did not own the file.  That is the source of the error
> > message.
> 
> This sounds like an accurate description of what's going on, and maybe
> our operating systems on these Linux/Solaris machines are working
> differently, or are configured differently.  However, as I noted before,
> the operation worked correctly on the Linux machines before I touched
> the Windows side, even though Linux doesn't show any change in
> permissions.  I know this should not be a Windows discussion, but it can
> be a filesystem discussion.  Is there something in the filesystem that
> might keep track of this Windows security (null) action, thus allowing
> me to suddenly change the ownership of the file on Linux?

What is the difference in strace output in the before and after cases?
I expect that there will be differences.  The differences should point
out what is happening.

Bob