On 23 Jan 2010, at 20:07, Markus Suvanto wrote: >> >> 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. >> >> I'm not sure how desirable that is, though, and making even more >> special-cases to the dropbox case doesn't sound appealing... > > 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 > > When customer log in the customers home directory looks like this: > upload ( permissions are "li") > donwload ( permissions are "lr) > > 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
