[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61764] Unwritable /dev/shm bug

From: Boud Roukema
Subject: [bug #61764] Unwritable /dev/shm bug
Date: Tue, 4 Jan 2022 15:28:35 -0500 (EST)
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-us) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2


                 Summary: Unwritable /dev/shm bug
                 Project: Maneage
            Submitted by: boud
            Submitted on: Tue 04 Jan 2022 08:28:33 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any



In the 'reproduce/software/shell/' script that
fixes bug, we first
create a directory, and then create
a test file '' in the new subdirectory
of '/dev/shm' and then check if that script can be run
by the user. See the section starting around lines 1304. [1]

Hypothetically, a system could have the '/dev/shm' device
but not permit the particular user to create directories and files there.
(Different users might be given different rights,
for example, or this might be a root-only RAM fs.) 

In that case, we don't want a fatal error, because we have the
safe fallback of not using /dev/shm.

I've tested this and there is a failure as expected.

I've put a proposed fix that seems to me to work correctly in all

To test the failure in commit 5641f4e and to see if commit 7d14eb7 [2] works
correctly, try various versions of

sudo mount -o remount,noexec /dev/shm
sudo mount -o remount,exec /dev/shm
sudo mount -o remount,ro /dev/shm
sudo mount -o remount,rw /dev/shm

and check what happens in _/dev/shm_ in the various cases, as 
well as whether the _./project configure_ script behaves as expected.




Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]