Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Apr 2021 10:42:32 -0700
From:      Chris <bsd-lists@bsdforge.com>
To:        Gleb Popov <arrowd@freebsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>
Subject:   Re: ACLs are not reflected in FS extended attributes
Message-ID:  <931a90dd52a1e5c2066c7aed4b79b9dc@bsdforge.com>
In-Reply-To: <8653ba21fd5339eef180e7f4db4a5a76@bsdforge.com>
References:  <CALH631m8bC5SoRhC1Q1X1%2BmN7tgT3Ti%2BTwhronSNZeX3Qn%2Bg-g@mail.gmail.com> <8653ba21fd5339eef180e7f4db4a5a76@bsdforge.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-04-27 10:20, Chris wrote:
> On 2021-04-27 01:41, Gleb Popov wrote:
>> Hello hackers.
>> 
>> I'm trying to implement Linux acl_extended_file() function [1] within our
>> libc. On Linux this function is implemented via getxattr, a function that
>> reads extended attributes from the file [2][3]
>> 
>> My implementation follows the Linux one:
>> 
>> 
>> int
>> acl_extended_file_np(const char *path_p)
>> {
>> return _acl_extended_file(extattr_get_file, path_p);
>> }
>> 
>> int _acl_extended_file(getattr_func f, const char* path_p)
>> {
>> int base_size = 9999; // figure out this later
>> int retval;
>> 
>> retval = f(path_p, POSIX1E_ACL_ACCESS_EXTATTR_NAMESPACE,
>> POSIX1E_ACL_ACCESS_EXTATTR_NAME, NULL, 0);
>> printf("Retval1: %d\n", retval);
>> if (retval < 0 && errno != ENOATTR)
>>   return -1;
>> if (retval > base_size)
>>   return 1;
>> retval = f(path_p, POSIX1E_ACL_DEFAULT_EXTATTR_NAMESPACE,
>> POSIX1E_ACL_DEFAULT_EXTATTR_NAME, NULL, 0);
>> printf("Retval2: %d\n", retval);
>> if (retval < 0 && errno != ENOATTR)
>>   return -1;
>> if (retval > base_size)
>>   return 1;
>> return 0;
>> }
>> 
>> 
>> However, when I tried to use it, I stumbled upon following differences:
>> 
>> - It requires root permissions to operate. I guess this is because it tries
>> to look at "system" extattr namespace.
>> - It doesn't work anyways due to "Attribute not found" error.
>> 
>> And indeed, the same behavior can be seen when using command line tools.
>> On Linux:
>> $ setfacl -m u:someuser:rwx somefile
>> $ getfattr -d -m - somefile
>> system.posix_acl_access=<mangled ACL data>
>> 
>> 
>> On FreeBSD:
>> $ setfacl -m u:someuser:rwx:allow somefile
>> $ sudo getextattr system posix1e.acl_access somefile
>> failed: Attribute not found
>> 
>> I guess that FreeBSD behaviour is actually not a bug and libacl just uses
>> some internal knowledge about how ACL/xattr is implemented on Linux. If
>> this is correct, how should I approach implementing this function on
>> FreeBSD?
>> 
>> Thanks in advance.
> Apologies in advance if I'm somehow off the mark here.
> But MacOS already does this. It might provide better examples for your
> needs.
> But as I understand it. The underlying file system needs to have space
> for, and be aware of your intentions in order to accomplish this. Which
> speaks to some degree to the error(s) you're receiving. Indeed. root
> will be the only one able fully see these attributes, unless you make
> some accommodations for user rights. IOW it'll somehow need to be
> incorporated with the permission setup already implemented in the
> existing file system.
> Again, if I've somehow glossed over your intentions, and missed something.
> My apologies.
OK. Sorry. You're looking to bolt this feature on via a lib.
I think permissions are going to be a hurdle here. Aren't they? I mean,
won't you need to add an additional field for this new attribute in/for
ls(1) to make any of this work?

--Chris
> 
> --Chris
>> 
>> [1] https://linux.die.net/man/3/acl_extended_file
>> [2]
>> http://git.savannah.nongnu.org/cgit/acl.git/tree/libacl/acl_extended_file.c
>> [3]
>> http://git.savannah.nongnu.org/cgit/acl.git/tree/libacl/__acl_extended_file.c
>> _______________________________________________
>> freebsd-hackers@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?931a90dd52a1e5c2066c7aed4b79b9dc>