NeilBrown wrote:
> Thanks for the review.
> As afs doesn't use the generic xattr code and doesn't call
> setattr_prepare(), this is all largely irrelevant for afs.
Yeah - there's no xattr support yet.
> afs_permission() will probably only get MAY_ACT_AS_OWNER passed when
> someone uses fcntl(F_
On Thu, Oct 04 2018, Jan Harkes wrote:
> Same for Coda.
>
> uid/gid/mode don't mean anything, access is based on the directory ACL and
> the authentication token that is held by the userspace cache manager and
> ultimately decided by the servers.
>
> Unless someone broke this recently and made p
On Thu, Oct 04 2018, David Howells wrote:
> NeilBrown wrote:
>
>> diff --git a/fs/afs/security.c b/fs/afs/security.c
>> index 81dfedb7879f..ac2e39de8bff 100644
>> --- a/fs/afs/security.c
>> +++ b/fs/afs/security.c
>> @@ -349,6 +349,16 @@ int afs_permission(struct inode *inode, int mask)
>> i
Same for Coda.
uid/gid/mode don't mean anything, access is based on the directory ACL and the
authentication token that is held by the userspace cache manager and ultimately
decided by the servers.
Unless someone broke this recently and made permission checks uid based I would
expect no change
NeilBrown wrote:
> diff --git a/fs/afs/security.c b/fs/afs/security.c
> index 81dfedb7879f..ac2e39de8bff 100644
> --- a/fs/afs/security.c
> +++ b/fs/afs/security.c
> @@ -349,6 +349,16 @@ int afs_permission(struct inode *inode, int mask)
> if (mask & MAY_NOT_BLOCK)
> return -EC
A few places in VFS, particularly set_posix_acl(), use
inode_owner_or_capable() to check if the caller has "owner"
access to the inode.
This assumes that it is valid to test inode->i_uid, which is not
always the case. Particularly in the case of NFS it is not valid to
us i_uid (or i_mode) for perm
6 matches
Mail list logo
