Re: shmctl(SHM_STAT) vs. /proc/sysvipc/shm permissions discrepancies
From: Michal Hocko <mhocko@kernel.org>
Date: 2017-12-20 09:13:32
Also in:
linux-mm, lkml
On Wed 20-12-17 09:44:47, Michael Kerrisk wrote:
Hi Manfred, On 20 December 2017 at 09:32, Dr. Manfred Spraul [off-list ref] wrote:quoted
Hi Michal, On 12/19/2017 10:48 AM, Michal Hocko wrote:quoted
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.Are you sure that this patch changed the behavior? The proc interface is much older.Yes, I think that's correct. The /proc/sysvipc interface appeared in 2.3.x, and AFAIK the behavior was already different from *_STAT back then.
I have probably misread the patch. It surely adds sysvipc_proc_fops, maybe there was a different implementation previously. I haven't checked. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>