[OpenAFS-devel] Re: safe dropboxing in an anonymous world

[Jeffrey Altman]

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

On 2/7/2011 11:54 AM, Andrew Deason wrote:
> On Mon, 7 Feb 2011 11:02:18 -0500
> Derrick Brashear <shadow@gmail.com> wrote:
>=20
>> The effect of the "or be owner and have insert access" is to allow
>> readback if for some reason you need to pull back from the server in
>> the process of writing something out for insert. In an "atomic write"
>> world this would not be necessary, and
>> in this world it is only dubiously so.
>=20
> If the client were improved to only write dirty bytes to the server,
> this could be avoided, yes?

The goal here is to provide AFS with Insert semantics.  Unfortunately,
because the file server has no notion of an "open fid" / "close fid"
operation there is no ability to permit read/write capabilities only to
the client that created the file and only until the file is "closed" for
the first time.

Instead, AFS makes a compromise.  The file server gives implicit
permission to read and write the contents of any file to any user that
has 'i' privilege provided that they are the 'owner' of the file.

The clients *may* then provide better Insert semantics by tracking the
file creation and first close locally.  However, this is not a
requirement of a client and in fact cannot be implemented in all clients.=


One side effect of this policy is that if "system:anyuser" is granted
"il" permissions, then any one in the world is able to list the contents
of the directory and read/write every file in that directory which was
created by an anonymous user.


>> In a directory which is system:anyuser li, this allows people to read
>> previous submissions. This is probably undesirable. It's simple to
>> avoid the problem this way, which the compromise that readback isn't
>> possible.
>=20
> I think arbitrary reads of this sort are currently prevented via
> client-side enforcement, right? So it would be difficult to do that
> accidentally.

The MacOS X client cannot enforce this restriction and any user can
modify any other client to remove this restriction.  As a result, it is
not sufficient to rely on the client.


>> Ignoring the broader question of "do we really want the readback
>> ever", comments on this revision?
>=20
> I think we'd need to advertise that s:anyuser dropboxes may not always
> work as expected, if you're depending on anonymous inserters.

This problem is not new and has been well-known in the AFS community for
quite some time.  The "What are dropboxes?" section (2.22) of the AFS
FAQ: Using AFS page includes the following:

"When the ACL on a directory is set to 'irl', this creates what is
called a 'dropbox'. In theory, users should be able to deposit files in
the directory, but not modify them once deposited.

"In practice, the 'not modify them once deposited' part is not enforced
by the fileserver; only the OpenAFS client enforces this restriction.
Thus, you should not depend on this for security.

"Also, note that system:anyuser=3Dirl has additional problems: because
dropbox semantics are based on pts identities (see question 2.21), the
fileserver cannot distinguish between two unauthenticated users. So, not
only can a user come back days later and modify the 'dropped' file, but
any user can modify a file dropped by an unauthenticated user, at any tim=
e."

Unfortunately, this is not documented either as part of the "fs setacl"
page or in the Adminstrators Guide.

My personal opinion is that anonymous users should not be permitted to
read from a dropbox file owned by anonymous unless the "r" right is
explicitly set.  If the "r" right is set for system:anyuser, then the
administrator has made an explicit decision to permit those files to be
read after they are deposited.  There is nothing we can do to prevent
clients from writing to or over pre-existing files in this case from the
perspective of the file server.

I think it would also be worth-while to have a file server option that
disables "i" for anonymous in its entirety.

Jeffrey Altman



--------------enig38E89F531DBED1E24217ACE3
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)

iQEcBAEBAgAGBQJNUDFQAAoJENxm1CNJffh4UgAH/128i9yYuS5FgqAg3YOHMgRS
YpyTqSUhQ2+Y22TpPZ4Z7zbX++ML50RDM75j0nH80LOWdK0kG34GJsVYk2yWNxes
hycWRJ7zYi01SZk+Y9N/MJwRChvL0iNONhZJyWd3YhGewbH64olo9d9iRlrkh6c+
y/GGo1oCr1RmiuZu7ZBdZS+fmkjpxjNuH7/y+WJoFFBmvdOkcSvL0XzA43MTNqZz
xOc3DNp3Bum/45Hgq4s3/FibiS9sK5ktg3XaEidGP1sXbqr1yxBaoKAXepheEUL8
jZ33PSmbd6kB9L2m29tXrnIls+s+Kn7mYvcVUJXC2WJ5Juj86btOCntafbA66GM=
=Urh0
-----END PGP SIGNATURE-----

--------------enig38E89F531DBED1E24217ACE3--