Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751600AbdLSQqG (ORCPT ); Tue, 19 Dec 2017 11:46:06 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:39542 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbdLSQqC (ORCPT ); Tue, 19 Dec 2017 11:46:02 -0500 X-Google-Smtp-Source: ACJfBoswi8ZKyGwGr8c+n5jUP9MAAlXsv2osTswkfGARkZA95BE0RmvmSwBNTRu30BSthUtSHCFzvjd9Bsdb/5MtpfQ= MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <20171219094848.GE2787@dhcp22.suse.cz> References: <20171219094848.GE2787@dhcp22.suse.cz> From: "Michael Kerrisk (man-pages)" Date: Tue, 19 Dec 2017 17:45:40 +0100 Message-ID: Subject: Re: shmctl(SHM_STAT) vs. /proc/sysvipc/shm permissions discrepancies To: Michal Hocko Cc: Linux API , Manfred Spraul , Andrew Morton , Al Viro , Kees Cook , Linus Torvalds , Mike Waychison , LKML , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3176 Lines: 81 Hello Michal, On 19 December 2017 at 10:48, Michal Hocko wrote: > Hi, > we have been contacted by our partner about the following permission > discrepancy > > 1. Create a shared memory segment with permissions 600 with user A using > shmget(key, 1024, 0600 | IPC_CREAT) > 2. ipcs -m should return an output as follows: > > ------ Shared Memory Segments -------- > key shmid owner perms bytes nattch status > 0x58b74326 759562241 A 600 1024 0 > > 3. Try to read the metadata with shmctl(0, SHM_STAT,...) as user B. > 4. shmctl will return -EACCES > > The supper set information provided by shmctl can be retrieved by > reading /proc/sysvipc/shm which does not require read permissions > because it is 444. > > It seems that the discrepancy is there since ae7817745eef ("[PATCH] ipc: > add generic struct ipc_ids seq_file iteration") when the proc interface > has been introduced. The changelog is really modest on information or > intention but I suspect this just got overlooked during review. SHM_STAT > has always been about read permission and it is explicitly documented > that way. Yes, this was always a weirdness on Linux. Back before we got /proc/sysvipc, it meant that ipcs(1) on Linux did not did not display all IPC objects (unlike most other implementations, where ipcs(1) showed everyone's objects, regardless of permissions). I remember having an email conversation with Andries Brouwer about this, around 15 years ago. Eventually, an October 2012 series of util-linux patches by Sami Kerola switched ipcs(1) to use /proc/sysvipc so that ipcs(1) does now show all System V IPC objects. > I am not a security expert to judge whether this leak can have some > interesting consequences but I am really interested whether this is > something we want to keep that way. Do we want to filter and dump only > shmids the caller has access to? Do you mean change /proc/sysvipc/* output? I don't think that should be changed. Modern ipcs(1) relies on it to do The Right Thing. > This would break the delegation AFAICS. > Do we want to make the file root only? That would probably break an > existing userspace as well. > > Or should we simply allow SHM_STAT for processes without a read permission > because the same information can be read by other means already? > > Any other ideas? The situation is certainly odd. The only risk that I see is that modifying *_STAT behavior could lead to behavior changes in (strange?) programs that expect SHM_STAT / MSG_STAT / SEM_STAT to return only information about objects for which they have read permission. But, is there a pressing reason to make the change? (Okay, I guess iterating using *_STAT is nicer than parsing /proc/sysvipc/*.) Cheers, Michael > -- > Michal Hocko > SUSE Labs > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/