From owner-freebsd-hackers@freebsd.org Tue Apr 27 17:20:35 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DED7E5F805C for ; Tue, 27 Apr 2021 17:20:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FV7nb3WGzz4fX9; Tue, 27 Apr 2021 17:20:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 13RHKiVx091346; Tue, 27 Apr 2021 10:20:51 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Tue, 27 Apr 2021 10:20:44 -0700 From: Chris To: Gleb Popov Cc: freebsd-hackers Subject: Re: ACLs are not reflected in FS extended attributes In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <8653ba21fd5339eef180e7f4db4a5a76@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FV7nb3WGzz4fX9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 17:20:35 -0000 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= > > > 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. --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"