From owner-freebsd-hackers@freebsd.org Tue Apr 27 17:42:23 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 C92555F92DF for ; Tue, 27 Apr 2021 17:42:23 +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 4FV8Gl3rnJz4gkK; Tue, 27 Apr 2021 17:42:22 +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 13RHgWEH068693; Tue, 27 Apr 2021 10:42:38 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Tue, 27 Apr 2021 10:42:32 -0700 From: Chris To: Gleb Popov Cc: freebsd-hackers Subject: Re: ACLs are not reflected in FS extended attributes In-Reply-To: <8653ba21fd5339eef180e7f4db4a5a76@bsdforge.com> References: <8653ba21fd5339eef180e7f4db4a5a76@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <931a90dd52a1e5c2066c7aed4b79b9dc@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: 4FV8Gl3rnJz4gkK 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:42:23 -0000 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= >> >> >> 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"