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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 05B01C433EF for ; Mon, 6 Sep 2021 01:40:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D74726101C for ; Mon, 6 Sep 2021 01:40:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240394AbhIFBlK (ORCPT ); Sun, 5 Sep 2021 21:41:10 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:33523 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S241205AbhIFBiS (ORCPT ); Sun, 5 Sep 2021 21:38:18 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1861au7Q027251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 5 Sep 2021 21:36:57 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id D62B315C3403; Sun, 5 Sep 2021 21:36:56 -0400 (EDT) Date: Sun, 5 Sep 2021 21:36:56 -0400 From: "Theodore Ts'o" To: Greg KH Cc: =?utf-8?B?5p2o55S35a2Q?= , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, security@kernel.org Subject: Re: Report Bug to Linux File System about fs/devpts Message-ID: References: <2f73b89f.266.17bb4a7478b.Coremail.nzyang@stu.xidian.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, Sep 05, 2021 at 07:20:01PM +0200, Greg KH wrote: > If you are concerned about this, please restrict the kernel.pty.max > value to be much lower. The kernel.pty.max value specifies the global maximum limit. So I believe the point solution to *this* particular container resource limit is to mount separate instances of /dev/pts in each container chroot with the mount option max=NUM, instead of bind-mounting the top-level /dev/pts into each container chroot. And we can use the rubber mallet to hit one more mole in the whack-a-mole game. :-) Or you can just assume that all of the containers are cooperatively trying to share the OS resources, and if there is a malicious container, it can be handled out-of-band by non-technical means (e.g., by having the Site Reliability Engineer tracking down owner of said malicious container, and then talking to their manager to tell them not to do that particular anti-social thing, docking the owner's social credit account, etc.). - Ted