[OpenAFS-devel] Re: Permission bug?

[Simon Wilkinson]

On 23 Jan 2010, at 20:07, Markus Suvanto wrote:

>>=20
>> It is _possible_ to make an exception for the 'dropbox' case, and =
grant
>> stat() permission to the owner but not let them read the file, since
>> preventing the owner from reading the file is enforced by the client =
and
>> not by the fileserver.
>>=20
>> I'm not sure how desirable that is, though, and making even more
>> special-cases to the dropbox case doesn't sound appealing...
>=20
> I think it is just what I need. My user case is ftp server. Every =
customer
> has own chrooted directory and the ftp server file space is under /afs
>=20
> When customer log in the customers home directory looks like this:
> upload      ( permissions are "li")
> donwload  ( permissions are "lr)
>=20
> Now customer can upload files to the upload directory and be sure
> that no one else can read/over write uploaded files (even if customers
> passwd is stolen). Customer don't know afs-permissions but one thing
> they do is "ls -la" after uploading files and if output is something =
like
> -????????? ? ?   ?      ?            ? uploaded_files
> they think that uploading is failed.

Perhaps I should explain some background here, for those following =
along...

There's been a long standing bug that stat() behaves differently when =
information is in the cache, compared to when it is not. The bug here, =
essentially, is that stat() doesn't make any access control decisions =
when returning meta-data information about a file. When the file isn't =
in the local cache, access control is performed by the fileserver, and =
the user will see question marks. If the file is cached, however, any =
user can see the full stat information of the file. This only leaks the =
mode bits, UID and GID of the owner, and filesize, so as information =
disclosures is relatively minor. However, it's also a usability issue, =
as users can't understand why sometimes they see full stat information, =
and on other occassions get screens full of question marks. For both =
reasons, it's something that we were keen to fix.

The original patch was designed to fix this problem, but sadly none of =
us anticipated the slightly special nature of the dropbox case. As =
others in this thread have noted, dropboxes are wierd because they are =
the one case in AFS where the exact access permissions are enforced by =
the client, and not by the server. So, we didn't account for that, and =
fell back to the standard rules which are that a user with 'li' doesn't =
have access to files that have been written to a dropbox. This meant =
that you could no longer stat() the files, and so you'd end up with the =
missing stat information.

Anyway, that's why we've been modifying that area of code. Whilst I'm =
still keen that we fix the stat() issue, it's becoming clear that this =
change has far bigger ramifications than we originally thought, and it =
may be that it's best to drop it from 1.4.12 entirely. We shall see.

Cheers,

Simon.