[OpenAFS] ubik_Call returns 363546 suddenly

[Benjeman Meekhof]

Thanks everyone for the information, and thanks again to Jeffrey for
more details off-list about some issues with the amanda-afs code.

I was able to get the util to work by changing a call to
vsu_ClientInit to use authentication and running with admin tokens.

regards,
Ben


On Sat, Mar 5, 2016 at 6:56 PM, Jeffrey Altman <jaltman@auristor.com> wrote:
> On 3/5/2016 3:00 PM, Benjeman Meekhof wrote:
>> I tracked this down to the following snippet of code.  In this code
>> ubik_Call returns a code of '363546', nentries is 0, and since we get
>> no volumes returned that's the end of any further action.  volname is
>> a wildcard string like "home..*".  I've tried pointing the command at
>> volume sets on any of our 3 file servers.
>
> The error is VL_PERM == Permission denied.
>
>> Can anyone on the list offer any further hints to tracking this down?
>> It appears that the beginning of this problem correlates to our
>> vlserver machines receiving a package update that moved from afs
>> 1.6.10 to 1.6.14.  We're not experiencing any other issues with AFS,
>> and until this point have not had any issue with this utility.
>
> Reading the Amanda "volset" source code the connection to the VL service
> is made using the "rxnull" security class. As such the connection is
> "anonymous" and the VL_ListAttributesN2 query is denied.
>
> The change in behavior is due to
>
>   http://www.openafs.org/pages/security/#OPENAFS-SA-2015-006
>
> Jeffrey Altman
>
>
>