Discussion:
ACLs are not reflected in FS extended attributes
Gleb Popov
2021-04-27 08:41:16 UTC
Permalink
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.

[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
Chris
2021-04-27 17:20:44 UTC
Permalink
Post by Gleb Popov
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]
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;
}
- 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.
$ setfacl -m u:someuser:rwx somefile
$ getfattr -d -m - somefile
system.posix_acl_access=<mangled ACL data>
$ 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.

--Chris
Post by Gleb Popov
[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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Chris
2021-04-27 17:42:32 UTC
Permalink
Post by Chris
Post by Gleb Popov
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]
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;
}
- 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.
$ setfacl -m u:someuser:rwx somefile
$ getfattr -d -m - somefile
system.posix_acl_access=<mangled ACL data>
$ 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
Post by Chris
--Chris
Post by Gleb Popov
[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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Ryan Moeller
2021-04-27 17:58:37 UTC
Permalink
ACLs on FreeBSD are not exposed through extended attributes but rather
acl(9) interfaces in VFS implemented by each filesystem. There is a
good selection of library interfaces already in acl(3).
acl_extended_file(3) looks like it could be pretty much a convenience
wrapper around acl_is_trivial_np(3). Hope that helps point you in the
right direction!

-Ryan
Post by Gleb Popov
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]
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;
}
- 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.
$ setfacl -m u:someuser:rwx somefile
$ getfattr -d -m - somefile
system.posix_acl_access=<mangled ACL data>
$ 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.
[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
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
--
Ryan Moeller
iXsystems, Inc.
OS Developer
Email: ***@iXsystems.com
Gleb Popov
2021-05-03 11:11:59 UTC
Permalink
Post by Ryan Moeller
ACLs on FreeBSD are not exposed through extended attributes but rather
acl(9) interfaces in VFS implemented by each filesystem. There is a
good selection of library interfaces already in acl(3).
acl_extended_file(3) looks like it could be pretty much a convenience
wrapper around acl_is_trivial_np(3). Hope that helps point you in the
right direction!
-Ryan
Thanks for your reply. Indeed, I used acl_is_trivial_np to implement this
function and it seems to work!

Continue reading on narkive:
Search results for 'ACLs are not reflected in FS extended attributes' (Questions and Answers)
3
replies
what is the importent of filesystem?
started 2008-01-09 03:55:24 UTC
earth day
Loading...