[Bug 271038] "posixshmcontrol ls" gets an error when another user restricts some shared memory
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271038] "posixshmcontrol ls" gets an error when another user restricts some shared memory"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271038] "posixshmcontrol ls" gets an error when another user restricts some shared memory"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271038] "posixshmcontrol ls" gets an error when another user restricts some shared memory"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 23 Apr 2023 23:07:56 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271038 Bug ID: 271038 Summary: "posixshmcontrol ls" gets an error when another user restricts some shared memory Product: Base System Version: 12.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: rau8344@gmail.com "posixshmcontrol ls" gets an error when another user restricts some shared memory, meaning the current user does not have access to it. The return code of the command is also 1, indicating the command failed, which could cause problems in certain scripting scenarios. Within the output table, a line for the inaccessible shared memory path is output: "posixshmcontrol: open <path>: Permission denied". Running as user1, output is like: MODE OWNER GROUP SIZE PATH rw-r--r-- user1 group1 1000 <some_path_a> posixshmcontrol: open <some_path_b>: Permission denied rw-r--r-- user1 group1 1000 <some_path_c> Running with sudo, output is like: MODE OWNER GROUP SIZE PATH rw-r--r-- user1 group1 1000 <some_path_a> rw------- user2 group2 1000 <some_path_b> rw-r--r-- user1 group1 1000 <some_path_c> The posixshmcontrol(1) docs say that the ls subcommand should "List all linked named shared memory segments visible to the caller." Since path owned by other user does NOT appear to be visible to the caller, the ls subcommand should probably ignore it completely. MODE OWNER GROUP SIZE PATH rw-r--r-- user1 group1 1000 <some_path_a> rw-r--r-- user1 group1 1000 <some_path_c> An alternative would be to add additional switches to control this behavior and allow suppressing this error. -- You are receiving this mail because: You are the assignee for the bug.