This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rsync problems from Vista installed cygwin, ok on XP



Igor Peshansky wrote:
> 
> On Mon, 20 Aug 2007, DaveB wrote:
> 
>> Corinna Vinschen-2 wrote:
>> >
>> > On Aug 18 21:06, DaveB wrote:
>> >> So... two interesting followon points...
>> >>
>> >> 1. Why didn't the ACLs get set to something reasonable as opposed to
>> >> 000 in the first place when I created this little test area in Vista?
>> >> After all, I
>> >
>> > The directory has been created using native Windows tools.  The
>> > permissions given using native Windows tools *are* strange and don't
>> > follow POSIX rules. It's perfectly valid that you can access a
>> > directory under Windows but get 000 POSIX permissions.  You did see
>> > the '+' at the end of the permission in ls -l?
>>
>> OK, I now see this + and had no idea what it meant... but have now found
>> the doc in cygwin by typing "info ls", where it says...
>>
>>      Following the file mode bits is a single character that specifies
>>      whether an alternate access method such as an access control list
>>      applies to the file.  When the character following the file mode
>>      bits is a space, there is no alternate access method.  When it is
>>      a printing character, then there is such a method.
>>
>>      For a file with an extended access control list, a `+' character is
>>      listed.  Basic access control lists are equivalent to the
>>      permissions listed, and are not considered an alternate access
>>      method.
>>
>> Interesting.  So if it knows there is an ACL which overrides the ------
>> permissions that were inherited from C:\ then why can't the cygwin port
>> of rsync allow a Windows-friendly option for rsync'ing these files...
>> even if it cannot directly read the ACL maybe it could allow you to
>> invoke some special rsync permissions sync'ing flag?
>>
>> I looked in the man rsync doc, and found some flags that might be
>> helpful ... namely -p -E and --chmod.  But even chmod=XXX doesn't quite
>> let you do automatically what would make sense, which is to create
>> rsync'd files with rwx for the exe's and rw for the others.
>>
>> Not sure what the best way out of here is...??? I'm beginning to
>> understand this a bit better, but it sure is a minefield... will
>> generate ongoing problems for innocent future users.
> 
> You misunderstand your problem.  The problem is not that rsync on the
> source side cannot read the files (it can, since the ACLs allow it to).
> The problem is that the rsync on the destination side copies only the Unix
> permission bits from the source side (which are 000), and then it is
> unable to write to that directory (because the permissions are 000).
> 
> What you want is some way of getting rsync to not copy permissions, or
> making rsync ACL-aware.  I don't know of any way to do either, but then, I
> haven't used rsync extensively.  Perhaps the documentation holds the
> answer.
> 
>> PS Can anyone point to a good article on ACL that explains the
>> relationship to these ls -l permissions also?
> 
> I'm sure MSDN has a lot of info on ACLs in general and on their use in
> Windows.  If you want to know specifically how Cygwin maps ACLs to Unix
> permission bits, see <http://cygwin.com/cygwin-ug-net/ntsec.html>.
> 	Igor
> 

Don't think I misunderstood... what I was saying above agrees with you - the
ACLs allow cygwin/rsync to read the files, but it then proceeds to transfer
the posix permissions, which are 000.
The ntsec article above is very helpful actually, explaining the problem
more clearly - there is a mismatch between posix and NT security. cygwin is
an environment trying to bridge the gap.

It seems that a good solution might be to provide a cygwin environment
variable which "OR"s the read/write access of the current user with the
posix flags right from the start... Then even an ls -l would come up with
rwx where applicable (instead of --- at the moment), and programs like
cygwin/rsync would then behave themselves and cause less of a surprise to
the end user.

My earlier comment said
>why can't the cygwin port of rsync allow a Windows-friendly option for
rsync'ing these files
If there was a Windows friendly env variable that made current ACL the
default reported security setting for the rwx flag (at least for the owner)
then there would be no need to fiddle with anything in rsync, fix the
problem upstream.  Cygwin does things like this in other areas - eg it
provides env variables for dealing better with the case dependence in
filenames which is fundamentally different between unix and Windows.  So why
not make it behave more like Windows in the security area?  Until it was
pointed out to me what was going on here, I was oblivious to the --- posix
setting and happily reading and writing files in this directory in Windows,
so of course it was a surprise when rsync's copy of the directory to a unix
system zapped the rwx setting of the directory copy up there.  As Igor is
saying, this is the underlying problem...

>The problem is not that rsync on the
>source side cannot read the files (it can, since the ACLs allow it to).
>The problem is that the rsync on the destination side copies only the Unix
>permission bits from the source side (which are 000), and then it is
>unable to write to that directory (because the permissions are 000).

I agree with this but think that rsync is not the problem here... the real
problem is the underlying behaviour of cygwin, which as we observe can read
the source files just fine, but tells rsync (and ls -l and everyone else)
that it cannot (000).  An environment variable to change this behaviour and
make some use of the ACLs when reporting the permission bits to rsync, ls -l
and anyone else who asks, would IMHO solve the problem more elegantly than
attacking each problem area (like rsync) individually.  In fact, rsync does
have flags which come close to letting one deal with this problem (--chmod=
discussed above) but I don't think this is the place to fix the problem. 
Cygwin is a great attempt to provide a unix like environment on Windows and
is saddled with the responsibility of dealing with these fundamental
incompatibilities - in the case of file name case dependence, it does such a
good job that I hadn't noticed there was a problem really... of  course
there is and there is no perfect solution.  Similarly, any attempt to use
ACLs has inherent problems too - the solution cannot be perfect, because
ACLs do not map 1-1 to the posix permission structure.  But the objective
should be to make the behaviour roughly like Windows at least... and at the
moment it is dramatically different.  (ie can read a file in Windows even
though permissions are reported as ---).

Having said all that, I must hasten to add - as I did earlier - that in my
case the problem is now totally resolved... I will be doing chmod -R's and
everything will work for me.  The discussion above is a suggestion for
making the cygwin environment "more Windows-compatible" and therefore
causing less surprises for users in general.  Cygwin/rsync is a great
environment and has solved a huge problem for me when dealing with backups
and ftp sites.  Can't praise it enough.  This permission stuff is a tricky
and near intractable problem, I just think that there is a way of improving
the behaviour here.
-- 
View this message in context: http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12246427
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]