apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: [PATCH] Adjust more_finfo() on Win32 to behave more like its Unix/Linux counterpart
Date Mon, 23 Jan 2006 23:02:01 GMT
On 1/21/06, Andreas Magnusson <andreas.ch.magnusson@home.se> wrote:
> I recently had a discussion with Garrett Rooney and William A. Rowe Jr.
>    about a bug in apr_file_open (on Windows in APR 0.9.7) that when
> fixed created "problems" in apr_stat (for Subversion). Spurred by this
> discussion, I decided to look for the root cause of the problem.
> And what I found was that apr_stat(&finfo, path, APR_FINFO_PROT, &pool)
> does indeed not behave (on Windows) as I imagine it would behave on
> Unix/Linux.
> The difference is that unpatched, the result in finfo.protection is
> *only* the world rights (translated into the group "Everyone" on
> Windows), and no group or user rights.
> With this patch, the finfo.protection includes the rights for the
> current user, and the rights for his/her primary group (plus of course
> world/Everyone). Which is much more like the way I believe it works on
> Unix/Linux.
> In more detail, more_finfo() asks for user and group information based
> on "(wanted & (APR_FINFO_USER | APR_FINFO_UPROT))" and vice versa for
> groups. But when it calls GetSecurityInfo (and friends depending on
> input), it only supplies the user argument if "(wanted & APR_FINFO_USER)".
> Which means that when the routine later checks if "user" is valid, it
> isn't, which means that when we in resolve_prot() check to see if we can
> use the user information, it fails. The interesting thing is that
> resolve_prot() seems to be written as if this scenario should work from
> the beginning.
> Note that I am by no means fluent in Unix/Linux, so if I have
> misunderstood that part, please set me straight immediately.

I'm not positive, not being an especially fluent win32 developer, but
I think this seems reasonable...  Would this patch be a replacement
for the backport you previously identified as avoiding the problem, or
is it in addition to it?


View raw message