[OpenAFS] Re: [OpenAFS-devel] Re: [AFS3-std] Changing RXAFS_GetVolumeStatus access check to support volume lock down

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig50A3B165E40869CD37A40EB1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/6/2012 9:16 AM, Harald Barth wrote:
> From: Jeffrey Altman <jaltman@secure-endpoints.com>
> Subject: Re: [OpenAFS-devel] Re: [AFS3-std] Changing RXAFS_GetVolumeSta=
tus access check to support volume lock down
> Date: Thu, 05 Jul 2012 18:48:26 -0400
>=20
>> On 7/5/2012 1:23 PM, Jeffrey Hutzelman wrote:
>>> I think it is fine to skip access control checks on this call entirel=
y.
>>> As you point out, the information available via this RPC is also
>>> available to unauthenticated clients via the volserver.
>>
>> I have modified http://gerrit.openafs.org/#change,7705 to remove all
>> access control checks.  I was being conservative by changing the check=

>> to RXAFS_LOOKUP but I am in agreement that the check is not needed at =
all.
>=20
> My cents after sleeping on it...
>=20
> When there is another door open to access the building, it is not very
> useful to check ID cards at the other.

Based upon the few comments that were received, I'm going to go ahead
and approve http://gerrit.openafs.org/#change,7705 with the intention
that this change be incorporated in the 1.6.2 release.

> If this would be "restricted information" then one would have to
>=20
>  (1) Close the unauthenticated method
>=20
>  (2) Figure out what WOULD BE a useful access restriction. I think
>      that (l) on the volume root is not good. The right access
>      restriction would IMHO be "open for any user that has (w) or (i)
>      in any directory of the volume". That check is a little more
>      tricky to implement but we don't need to think about it until (1)
>      is changed.

I will start a new thread on openafs-devel to discuss the question of
viable authorization checks on the VL and VOL interfaces since at the
moment there is no authorization data to use to enforce such checks.

Jeffrey Altman



--------------enig50A3B165E40869CD37A40EB1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQAvX8AAoJENxm1CNJffh4Z2IIAN0JFlZ+P5jmpZhNjxs8ELsE
oe7WdIbCaYd16M6vJjjwckvYxr8ldYdsTm5DtBTs2EETwatLXtDO2RI0403ON+B1
+AGqM04R1HSAXZ+0tRsMY6SLq5kb8Z15zs6wZl0uIFPBcu6ujKvserrwg9WKERgH
JJ4sxJK0+h/eDIkHi+5V++VDH+oHlix8k3GrHqW2g4bgHStIb8+u/YYMQCsWJOVG
3PsEf70enawbo/0X5ouoSQjsJWY6jkneZZ5s9q9Ay1WZex7u8Z5PHUWZkswmw1gW
wIJn91WwcDQck+YjlCWtLQVpDmYWoLe1prc/HHJKK0RDTUpFr0eofGfg8NWbwkA=
=qA9c
-----END PGP SIGNATURE-----

--------------enig50A3B165E40869CD37A40EB1--