Re: [Acl-devel] [PATCH] acl_{set,get}_file nofollow variants

[Andreas Grünbacher]

2018-03-07 2:47 GMT+01:00 Aaron Knister <address@hidden>:
> On 3/6/18 6:08 PM, Andreas Grünbacher wrote:
>>
>> 2018-03-06 23:00 GMT+01:00 Aaron S. Knister
>> <address@hidden>:
>>>
>>> Add act_set_file and acl_get_file nofollow variants to allow one to
>>> relatively safely operate on paths without inadvertently following a
>>> symbolic link.
>>
>>
>> There is precedent for nofollow variants because we have
>> acl_extended_file_nofollow. A related problem is that acl_get_fd
>> doesn't take a type argument, so I'm wondering if it would make sense
>> to support an openat-like interface instead, e.g.,
>>
>>    acl_t acl_get_at(int dirfd, const char *path, acl_type_t type, int
>> flags);
>>    int acl_set_at(int dirfd, const char *path, acl_type_t type, acl_t
>> acl, int flags);
>>
>> With AT_FDCWD as a possible value for dirfd, and AT_EMPTY_PATH and
>> AT_SYMLINK_NOFOLLOW as possible values for flags. The xattr syscalls
>> don't follow this pattern either, so a little bit of trickery would be
>> required, though.  New *xattrat syscalls would help of course.
>>
>
> Thanks, Andreas. Were you thinking the acl_*_at routines would still call
> f*xattr exclusively or might use l*attr to implement some of the flags?

Of course the *attr and l*attr operations would be used where
appropriate. The problems I see is that operations with dirfd !=
AT_FDCWD && path != "" cannot be implemented efficiently (they require
using openat), and I believe dirfd != AT_FDCWD && path != "" &&
AT_SYMLINK_NOFOLLOW for symlinks cannot be implemented at all because
f*xattr doesn't take O_PATH file descriptors. The latter could
probably be seen as a bug in f*xattr.

> It's been a while since I looked at this but I believe the trouble I found
> way back when was f*xattr didn't work for me. I can't recall exactly why but
> I think part of it was I couldn't give the AT_SYMLINK_NOFOLLOW flag to
> fgetxattr (so I wasn't quite sure if i'd followed a symlink reading the
> xattrs) and calling open() on half a billion files (to get the fd to pass to
> fgetxattr) on a clustered filesystem had some performance implications that
> calling lgetxattr didnt have. It's also very possible I don't understand
> what you're suggesting, so please forgive me if that's the case.

AT_SYMLINK_NOFOLLOW doesn't make sense for the f*xattr operations
because those operations don't perform any name resolution. I'm not
really sure what problem you ran into.

Andreas