From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow3-smtp.messagingengine.com (flow3-smtp.messagingengine.com [103.168.172.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE42D145B0F; Fri, 26 Apr 2024 17:38:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714153127; cv=none; b=X7a+K6UN4mK0LsKHo0IzL9llPspgTIUJZ8Fe1AjXmUnlu1sn0/Tk/3jqR/oncj07+KBsLX1FIdN56fHw/cLhcvUr4bl9ydfXxUWcBwhht1ZCBJnIV6kbTD08P9a9jiVF1xVV1jy8u3jIAtoya66iSxNSXTFXoNUg6KVzioJ/lvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714153127; c=relaxed/simple; bh=wl2WeNXK9401gewnNEkP62crFh93PXjbpWk6KFoepOg=; h=MIME-Version:Message-Id:In-Reply-To:References:Date:From:To:Cc: Subject:Content-Type; b=Y8SGQ32kfI8Kwf0xVrYeacufgyssYCHjxU+kKAQBk4O4/QvJlD8VtfHb2AJUZ2py1HDAxRBaykGIPwuP7dSTM2LxdxIy4pBG3OsLoyhD+DzAklo7ThJQvmGICvw0XbXkF0s4x4+4raW4th9GGKZO9ZPvoNvzYyqoMJTHSMh+FRQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=pE1T08Fu; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=aqFcdXIb; arc=none smtp.client-ip=103.168.172.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="pE1T08Fu"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="aqFcdXIb" Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailflow.nyi.internal (Postfix) with ESMTP id BDA42200567; Fri, 26 Apr 2024 13:38:43 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Fri, 26 Apr 2024 13:38:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1714153123; x=1714160323; bh=LvCKd10h8SxIpHH2VnKSem369EuCERsZx0vTF5ejpQk=; b= pE1T08FuMVdjjQLWiDkQO7xl56PeI7A1H3IWG3+rFD9emD//4B5RuAiqikq3csH2 HcrEwfg47R7YMmaz8Ciyl2cvIz4VVX096uNe1CYFtwsais2/erVg/FW25ZTMJvXr zpR/9AJQ+kMYwmkwNH/UDIyDG/M/RiXZfW1Gpp3WoGzKEMmORD8LrQExf4Uw72vT cf90JKVFYzecW30Y+7oynhwhYveQbKpD0A+7InyVTw6kiDVyu6WAufjR97YB+AAf 0ZE2OG1WQzxkmWcmeCmxI8V9AL9FQ/NFoFlVnxKbEzgyPDaqo7Ijv+GlzReYpZG8 UpsdbHxgZ38tWGTiNz9nEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1714153123; x= 1714160323; bh=LvCKd10h8SxIpHH2VnKSem369EuCERsZx0vTF5ejpQk=; b=a qFcdXIb7SbWdXzU54WGeWh/iceHLfbpvJPUdGWHPNnK5IEK/9AtOR5J2UG7I0kdd gA+bX/lBwFYGTyhrH0iOL1YwgOqj4CO02fhLgSpzb0errJKY1KqMkKtdiEMGW0IU avALV8VE2nPoBWWc5kPZjknu85rpxsTco30NFcpJL3ouXip8e9tY6t5C0m3yG4DV i9SMC7BAXFVXlTkQ12jergSGdPKhcHmwu/rclcCs4OnoitPkDQ5s/pDGcdD2HxtV 6evA3UfMGPMVusCn1+pAQOhpgJIj12adXuHnNCAk7/cjvkYwvImsSZiLSUZbVdMm WuinBDiPHs317sdol2J0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudelledgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf tehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrf grthhtvghrnhepgeefjeehvdelvdffieejieejiedvvdfhleeivdelveehjeelteegudek tdfgjeevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 324F9B60099; Fri, 26 Apr 2024 13:38:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-386-g4cb8e397f9-fm-20240415.001-g4cb8e397 Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <63ae53af-023d-444c-9571-8aef9e87ebc0@app.fastmail.com> In-Reply-To: <20240426162042.191916-1-cgoettsche@seltendoof.de> References: <20240426162042.191916-1-cgoettsche@seltendoof.de> Date: Fri, 26 Apr 2024 19:38:18 +0200 From: "Arnd Bergmann" To: cgzones@googlemail.com Cc: x86@kernel.org, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org, audit@vger.kernel.org, Linux-Arch , linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Russell King" , "Catalin Marinas" , "Will Deacon" , "Geert Uytterhoeven" , "Michal Simek" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Michael Ellerman" , "Nicholas Piggin" , "Christophe Leroy" , "Aneesh Kumar K.V" , "Naveen N. Rao" , "Heiko Carstens" , "Vasily Gorbik" , "Alexander Gordeev" , "Christian Borntraeger" , "Sven Schnelle" , "Yoshinori Sato" , "Rich Felker" , "John Paul Adrian Glaubitz" , "David S . Miller" , "Andreas Larsson" , "Andy Lutomirski" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "H. Peter Anvin" , "Chris Zankel" , "Max Filippov" , "Alexander Viro" , "Christian Brauner" , "Jan Kara" , "Paul Moore" , "Eric Paris" , "Jens Axboe" , "Pavel Begunkov" , "Peter Zijlstra" , "Sohil Mehta" , "Palmer Dabbelt" , "Miklos Szeredi" , "Nhat Pham" , "Casey Schaufler" , "Florian Fainelli" , "Kees Cook" , "Rick Edgecombe" , "Mark Rutland" , io-uring@vger.kernel.org Subject: Re: [PATCH v3 2/2] fs/xattr: add *at family syscalls Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2024, at 18:20, Christian G=C3=B6ttsche wrote: > From: Christian G=C3=B6ttsche > > Add the four syscalls setxattrat(), getxattrat(), listxattrat() and > removexattrat(). Those can be used to operate on extended attributes, > especially security related ones, either relative to a pinned directory > or on a file descriptor without read access, avoiding a > /proc//fd/ detour, requiring a mounted procfs. > > One use case will be setfiles(8) setting SELinux file contexts > ("security.selinux") without race conditions and without a file > descriptor opened with read access requiring SELinux read permission. > > Use the do_{name}at() pattern from fs/open.c. > > Pass the value of the extended attribute, its length, and for > setxattrat(2) the command (XATTR_CREATE or XATTR_REPLACE) via an added > struct xattr_args to not exceed six syscall arguments and not > merging the AT_* and XATTR_* flags. > > Signed-off-by: Christian G=C3=B6ttsche > CC: x86@kernel.org > CC: linux-alpha@vger.kernel.org > CC: linux-kernel@vger.kernel.org > CC: linux-arm-kernel@lists.infradead.org > CC: linux-ia64@vger.kernel.org > CC: linux-m68k@lists.linux-m68k.org > CC: linux-mips@vger.kernel.org > CC: linux-parisc@vger.kernel.org > CC: linuxppc-dev@lists.ozlabs.org > CC: linux-s390@vger.kernel.org > CC: linux-sh@vger.kernel.org > CC: sparclinux@vger.kernel.org > CC: linux-fsdevel@vger.kernel.org > CC: audit@vger.kernel.org > CC: linux-arch@vger.kernel.org > CC: linux-api@vger.kernel.org > CC: linux-security-module@vger.kernel.org > CC: selinux@vger.kernel.org I checked that the syscalls are all well-formed regarding argument types, number of arguments and (absence of) compat handling, and that they are wired up correctly across architectures I did not look at the actual implementation in detail. Reviewed-by: Arnd Bergmann