Sean O'Malley wrote: > Our users are getting confused with the 'list' permission and the Windows > client. The Windows afs client -will- show 0k files if you have the list > permission,
'lookup' and not 'read'. In other words, the real stat info is not available to the user. So we report the fact that the file exists but hide all of the details of the type of object (file, symlink, mount point, etc) > but in the Windows Explorer "properties get/show change > permissions" box thing, they see that it is set to read-only box is > checked when in fact it is not read only, it is list only. The read-only attribute will be set if the volume is readonly. We do not set the read-only attribute as part of the fake status info we generate when the user only has lookup permission. > In contrast, if they go through the afs->smb gateway, samba > doesn't show the file because they don't have read permissions. (it > ignores the list acl.) They either think, the smb-gateways do not work, > or they lost their files so we end up with a phone call. The fact that the Samba servers refuse to respect the lookup permission is a bug in the Samba servers. > This inconsistancy is causing confusion and frustration with our users and > our helpdesk. > Can we have the default be "list" doesn't show any files in the Explorer? I don't understand why you would want this? If the users' files disappear because they don't have tokens, you will get a call. That is exactly the behavior that the users do not like with the Samba servers. > Or at least not have the checkbox come back and say they have read-only > permissions when in fact they don't. This statement does not make sense to me. The "readonly" attribute is not a permission. It is a statement that the object cannot be changed either because the underlying volume is readonly or because the file has been marked with the readonly attribute. For an anonymous user the readonly flag can only be set if the volume is readonly or if the user has 'read' permission and the attributes on the file state that it is in fact readonly. > We can potentially make an override > advance preference for advanced users. (I am sure there are good reasons > to make list permissions list files, however, that is a more advanced > topic then some of our users can handle.) > > Should I file this as a bug report? I am not sure if this is by design, or > if it is a legitimate bug because it is setting the read-only flag for the > file. This is not a bug. If you do not want your users to see files they cannot read there is a very simple answer: Do not give them lookup privileges. Then they will not be able to see the files under any circumstances. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
