From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 975C61F47C for ; Mon, 16 Jan 2023 19:16:35 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=K5mNick8; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHUxu-0002Et-Qt; Mon, 16 Jan 2023 14:16:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHUxl-0002EX-Js; Mon, 16 Jan 2023 14:16:10 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHUxh-0007M6-IK; Mon, 16 Jan 2023 14:16:08 -0500 Received: by mail-wm1-x32e.google.com with SMTP id k16so62516wms.2; Mon, 16 Jan 2023 11:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=WwdPRDv+6h3ncRGyL2wIloPE2a/OWdIn0I/fjAHKJNA=; b=K5mNick8Uvs+Hpx3frzueS+0kQf6YSsQtU2981Fd8/hY8MaOlhUul1Oywo75RXAvTw Vk4TyJIFEZam92ED1NJMzw2bnfBANiGvG+c1rL2DCHymtVo8R9wwC4L+WnX5Rxf6V9qC GcLsYZfTARBIMrCVvg1SK4Wo2jltjeJiW/heenDsjw5kRhlfIp15sryMxosotFFdMAgk LKaoPMuePrx8PyCWc+PeQsrb7Fa3XgOpX/im2FRIEP1x/MYD4nBK61F3CMlTmW9YB2Ty Y/XFzkF15HZzYfhj1lM6CC69BgYpuN+1aDqTKUuW7ij4DfUD89jtvYbjuQFQ2RTd6vSh 5DxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WwdPRDv+6h3ncRGyL2wIloPE2a/OWdIn0I/fjAHKJNA=; b=nzUFz0P6lm+bApqvj2PTBNeGc48RlaPFw+kasaowgcYBJWMwOFf9Ff852m2QLWLA0Q n8tZdJ3UNjcbsNe6iNToeFLt9ZYrdT283tgoO6XrDlFO7QsGHuOJelmjOmAJ8y5mMAZJ rBek0hLV0Z8NKr9f6C67yEcfPqzUjS1PRWpFBmH+CbnEvdc5McWJdm400yTtpTDnS6tC Zlb2nuWk3kjellxEvU2xOifRNT5vTc5W/yezPectK0qLOWoFfivYg0FGjlOAUj6Hrxbw LbjDdI2zvVMD0EzVVLtaziU/9Gxl93qF79cHDiFPjzHN3u89b2RevmqqUEK7IYNuNq7/ zR/A== X-Gm-Message-State: AFqh2koC8JW2rU5xi1OifkWzOSEz3UKhdmuMBdxqP7DxIr2EnDwdWBNU jjypj/tIkO6hWnwUfNRxl6eaXakOU9A= X-Google-Smtp-Source: AMrXdXsCZJPzSUCl/qQ/mHjw+UuBdqC96mjFMHB7U46It+lUiPcITlpesJxmthYIAqfLiJ60NIYOAQ== X-Received: by 2002:a05:600c:3ac8:b0:3da:f67c:aca6 with SMTP id d8-20020a05600c3ac800b003daf67caca6mr521903wms.34.1673896554611; Mon, 16 Jan 2023 11:15:54 -0800 (PST) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id m5-20020a05600c3b0500b003c6b7f5567csm15769904wms.0.2023.01.16.11.15.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Jan 2023 11:15:54 -0800 (PST) Message-ID: Date: Mon, 16 Jan 2023 19:15:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0 Subject: Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way To: Ondrej Valousek , "coreutils@gnu.org" Cc: "bug-gnulib@gnu.org" References: Content-Language: en-US From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=pixelbeat@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.097, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org On 16/01/2023 15:03, Ondrej Valousek wrote: > Hi, > > As per our conversation with Bruno I was thinking if it would make a sense to extend support of ACLs in gnulib/coreutils, mainly covering "ls" (1st stage) and "chmod" (2nd stage) with the goal to have the ACLs better understandable for end users. > > For "ls" we would: > - Introduce a new flag "-V" that would work like "-l" but also append text interpretation of ACLs as in Solaris, i.e.: > # ls -V > total 7 > -rw-r--r--+ 1 root root 5 Jan 4 09:11 acl > user:ondrej:rwx-----------:-------:allow > owner@:rw-p--aARWcCos:-------:allow > group@:r-----a-R-c--s:-------:allow > everyone@:r-----a-R-c--s:-------:allow > > For "chmod" we would add new option "A" that would allow modify ACEs like in Solaris: > # chmod A+user:marks:rw- file.1 > > Technical implementation: > - I'd like to support NFSv4 ACLs, but since we have no library for it, then we would need to provide some parsing code for it and stick in Gnulib - we have something in "file-has-acl.c" already and it would be a good starting point. > - file_has_acl() function would need to be modified slightly to return 2 in case NFSv4 acls were found (this is backward compatible). > > For Posix acls we would use the existing libacl. > > Is this something I would find support in both coreutils and Gnulib? > Thanks Maybe, though I'm not convinced about adding to ls and chmod. This would add lots more complexity for parsing ACLs on input and output. Now saying that, there is some precedence with SELinux attributes generally integrated through the -Z option. For completeness, if "additional attributes" manipulation we have: ACLS: {get,set}facl Capabilities: {get,set}cap SELinux: getfattr -m 'selinux' -d,chcon xattrs: {get,set}fattr linux extra attributes: {ls,ch}attr So as we see there are lots of "additional attributes" with dedicated programs to manipulate them. What's the big advantage of merging with ls and chmod, over the current situation of separate utilities? Also there is the question of whether ACLs are always available. ext4 or nfs could be mounted with noacl for example, or some file systems may need acl support enabled with a mount option. Personally I feel we're exposing lots of complexity here for not much gain. thanks, Pádraig