From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AE7FC33C9E for ; Thu, 30 Jan 2020 10:12:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CEF29206D5 for ; Thu, 30 Jan 2020 10:12:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="V3NS23KS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727166AbgA3KM1 (ORCPT ); Thu, 30 Jan 2020 05:12:27 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38152 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727089AbgA3KM1 (ORCPT ); Thu, 30 Jan 2020 05:12:27 -0500 Received: by mail-oi1-f193.google.com with SMTP id l9so2953166oii.5 for ; Thu, 30 Jan 2020 02:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HweezRJJkHLXAQM17V6r2vAFwQaD4linYkes/t1atI4=; b=V3NS23KSrq4MUvaBdoyUEfolsItv3A83zERb1qrhKDntr8XV+eKK51lkHD9dVW7mF7 OS6M1ltybOZzMLHNJBoTW1H43OoxiUoNIXCzQD9ejEyvnPYMFdG8eWEf/mt+C+rEtoeY 4+FqxugvaNqHyfY25X+0aWRhMIoVg4AZYiy4m929uWdtYaCkaBeBBqf9Sle2WxQ+sB4M dECNfYMhBDb/JMjuGAU5gboTw0F8xAxPrPcFAebWqN6e1LT7U5Tn/Jx5U4GRDDjJMBk/ yXH3XOCugu+6+wEgU8ZmokOYcdiEIOn5D68tjyXKdSbcRiWR7vKK1738t9fQfkjeb7w1 vl9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HweezRJJkHLXAQM17V6r2vAFwQaD4linYkes/t1atI4=; b=NGtqDzg6BWijSKUe6PURr9yNY/wS0kXMSlBSRSYZuiIbAp4LV9Mssd3ul7W3gvrM2i R3lt3asfAzd2L39OIORpebO7KHPz2uygtV2nu3KPTi1KsJb9HeotfR7UpHsPecSd3obQ do5pPucF2H3xcCF7EwDLhR3Ls8MKUr/i1lQBOoGtsutwzpu7+mSpd4ecq6xMAWqjz8mo qQ6mzqvIaNXUSBtdrr3Vu5Js+FOOM13GN5NHzO1md+6PCmSVy86ODtNFUpnvNJwXySvs ex42t5piSstp5Zj6pge+x9dDiGdcDvgtOiFcVA7az33/FJe3UE9orzAA4e3/xIuACE04 PFnw== X-Gm-Message-State: APjAAAWwulnQjCIAnvvcxLdg8N+ijpatMAhKU/4Jz7KfrbeZrQX4vHek Nfx9wGqF99SGpmLsCaGY9MJq4Ca9Np9rHpna+64wDQ== X-Google-Smtp-Source: APXvYqy6H4WmPjVmgpyNjwhcoXUOfTsbXfjwNt9uFIXwCxydRgfmteQfXYPp1KvskqLMGQn/vf7nvDKpLwY23qRZ7hQ= X-Received: by 2002:aca:c7cb:: with SMTP id x194mr2355525oif.157.1580379146389; Thu, 30 Jan 2020 02:12:26 -0800 (PST) MIME-Version: 1.0 References: <688e187a-75dd-89d9-921c-67de228605ce@samba.org> <1ac31828-e915-6180-cdb4-36685442ea75@kernel.dk> <0d4f43d8-a0c4-920b-5b8f-127c1c5a3fad@kernel.dk> <4f833fc5-b4c0-c304-c3c2-f63c050b90a2@kernel.dk> <9ce2e571-ed84-211a-4e99-d830ecdaf0e2@kernel.dk> In-Reply-To: <9ce2e571-ed84-211a-4e99-d830ecdaf0e2@kernel.dk> From: Jann Horn Date: Thu, 30 Jan 2020 11:11:58 +0100 Message-ID: Subject: Re: IORING_REGISTER_CREDS[_UPDATE]() and credfd_create()? To: Jens Axboe Cc: Stefan Metzmacher , io-uring , Linux API Mailing List , Pavel Begunkov Content-Type: text/plain; charset="UTF-8" Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, Jan 30, 2020 at 2:08 AM Jens Axboe wrote: > On 1/29/20 10:34 AM, Jens Axboe wrote: > > On 1/29/20 7:59 AM, Jann Horn wrote: > >> On Tue, Jan 28, 2020 at 8:42 PM Jens Axboe wrote: > >>> On 1/28/20 11:04 AM, Jens Axboe wrote: > >>>> On 1/28/20 10:19 AM, Jens Axboe wrote: > >> [...] > >>>>> #1 adds support for registering the personality of the invoking task, > >>>>> and #2 adds support for IORING_OP_USE_CREDS. Right now it's limited to > >>>>> just having one link, it doesn't support a chain of them. > >> [...] > >>> I didn't like it becoming a bit too complicated, both in terms of > >>> implementation and use. And the fact that we'd have to jump through > >>> hoops to make this work for a full chain. > >>> > >>> So I punted and just added sqe->personality and IOSQE_PERSONALITY. > >>> This makes it way easier to use. Same branch: > >>> > >>> https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs-creds > >>> > >>> I'd feel much better with this variant for 5.6. > >> > >> Some general feedback from an inspectability/debuggability perspective: > >> > >> At some point, it might be nice if you could add a .show_fdinfo > >> handler to the io_uring_fops that makes it possible to get a rough > >> overview over the state of the uring by reading /proc/$pid/fdinfo/$fd, > >> just like e.g. eventfd (see eventfd_show_fdinfo()). It might be > >> helpful for debugging to be able to see information about the fixed > >> files and buffers that have been registered. Same for the > >> personalities; that information might also be useful when someone is > >> trying to figure out what privileges a running process actually has. > > > > Agree, that would be a very useful addition. I'll take a look at it. > > Jann, how much info are you looking for? Here's a rough start, just > shows the number of registered files and buffers, and lists the > personalities registered. We could also dump the buffer info for > each of them, and ditto for the files. Not sure how much verbosity > is acceptable in fdinfo? At the moment, I personally am just interested in this from the perspective of being able to audit the state of personalities, to make important information about the security state of processes visible. Good point about verbosity in fdinfo - I'm not sure about that myself either. > Here's the test app for personality: Oh, that was quick... > # cat 3 > pos: 0 > flags: 02000002 > mnt_id: 14 > user-files: 0 > user-bufs: 0 > personalities: > 1: uid=0/gid=0 > > > diff --git a/fs/io_uring.c b/fs/io_uring.c > index c5ca84a305d3..0b2c7d800297 100644 > --- a/fs/io_uring.c > +++ b/fs/io_uring.c > @@ -6511,6 +6505,45 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit, > return submitted ? submitted : ret; > } > > +struct ring_show_idr { > + struct io_ring_ctx *ctx; > + struct seq_file *m; > +}; > + > +static int io_uring_show_cred(int id, void *p, void *data) > +{ > + struct ring_show_idr *r = data; > + const struct cred *cred = p; > + > + seq_printf(r->m, "\t%5d: uid=%u/gid=%u\n", id, cred->uid.val, > + cred->gid.val); As Stefan said, the ->uid and ->gid aren't very useful, since when a process switches UIDs for accessing things in the filesystem, it probably only changes its EUID and FSUID, not its RUID. I think what's particularly relevant for uring would be the ->fsuid and the ->fsgid along with ->cap_effective; and perhaps for some operations also the ->euid and ->egid. The real UID/GID aren't really relevant when performing normal filesystem operations and such. > + return 0; > +}