xfs
[Top] [All Lists]

Re: acl_extended_file() broken?

To: Ethan Benson <erbenson@xxxxxxxxxx>
Subject: Re: acl_extended_file() broken?
From: Nathan Scott <nathans@xxxxxxx>
Date: Tue, 4 Jun 2002 09:15:33 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20020603044347.I13201@xxxxxxxxxxxxxxx>; from erbenson@xxxxxxxxxx on Mon, Jun 03, 2002 at 04:43:47AM -0800
References: <20020603044347.I13201@xxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
hi Ethan,

On Mon, Jun 03, 2002 at 04:43:47AM -0800, Ethan Benson wrote:
> ...
> afaict it uses the libacl function acl_extended_file() to check
> whether a file/dir has an actual acl associated, it appears to use
> this function correctly so i wrote a test program and found this
> function appears to be lying:
> ...
> am i missing something? the way i read the man page it should return 0:
> 
>      The acl_extended_file() function returns 1 if the file or directory
>      referred to by the argument path_p is associated with an extended access
>      ACL, or if the directory referred to by path_p is associated with a
>      default ACL. The function returns 0 if the file has neither an extended
>      access ACL nor a default ACL.
> 

Yeah, I see the problem now.  Basically, Andreas and I interpreted
this differently, and now that I read the current man page again,
looks like I've implemented it incorrectly in XFS.  This acl call
is implemented using getxattr with size==0 -- I had originally
interpreted this as "return size of a buffer large enough to hold
the EA value" ... and this probably was the semantics at some point
while the syscall discussions were going on.  I see the current man
page - getxattr(2) - is explicit on this being the current size.

This shouldn't be too hard to fix in XFS, I expect to have some new
code later today to correct this.

thanks.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>