Mail Archives: cygwin-developers/2003/02/14/10:48:23
Corinna Vinschen wrote:
>
> On Thu, Feb 13, 2003 at 10:08:30AM -0500, Pierre A. Humblet wrote:
> > Christopher Faylor wrote:
> > > Ok, what's causing these type of problems in 1.3.20? There has been a
> > > few of these reported.
> >
> > > > Please post the output of 'ls -l ../gcc-3.2.1/configure.in'.
> > > -rwx------+ 1 Administ Entwickl 55070 Jul 8 2002
> > > ../gcc-3.2.1-ov/configure.in
> >
> > Not sure how bash looks up the access mode.
> > I have some evidence that access() is broken but can't debug until tonight.
>
> I can't reproduce it. I've changed an executable to have the above
> permissions and the admins group as owner and I was able to call
> the executable with any of the shells, ash, bash and tcsh.
I haven't tried to reproduce it but there is definitely a bug in internal_getgroups
(introduced on 2003-02-04), which may explain it. Patch on the way.
Also looking at the logic in acl_access
if ((!(flags & R_OK) || (acls[i].a_perm & S_IROTH))
&& (!(flags & W_OK) || (acls[i].a_perm & S_IWOTH))
&& (!(flags & X_OK) || (acls[i].a_perm & S_IXOTH)))
return 0;
it looks like we only return OK if a single acl grants all the requested rights,
but we fail if say one acl grants R_OK and another one grants W_OK and we need
both.
I am thinking of redoing acl_access by using the MS AccessCheck() function.
This will take care of the issue above, make the call completely independent of
the passwd and group files and better handle access_denied ACE's.
Any thought?
Pierre
- Raw text -