Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
/dev/shm permissions at CentOS
874 views
Skip to first unread message
Aristidis Fesarlis
Sep 25, 2012, 3:41:03 AM9/25/12
to
Hi all,
I utilize /dev/shm as temporary directory for some applications.
However, even though I set the permissions to 1777 at startup, they seem
to change later. 't' permission is lost, and this results that my
applications cannot write to it when they run as users other than root.
I've come with a simple workaround, a cron job that resets the
permissions every minute. But this is not satisfying.
So I'd like to ask why this happens, and how to solve it. I use CentOS
5.8 x86.
Thanks all
I utilize /dev/shm as temporary directory for some applications.
However, even though I set the permissions to 1777 at startup, they seem
to change later. 't' permission is lost, and this results that my
applications cannot write to it when they run as users other than root.
I've come with a simple workaround, a cron job that resets the
permissions every minute. But this is not satisfying.
So I'd like to ask why this happens, and how to solve it. I use CentOS
5.8 x86.
Thanks all
Aragorn
Sep 25, 2012, 10:10:25 AM9/25/12
to
On Tuesday 25 September 2012 09:41, Aristidis Fesarlis conveyed the
following to comp.os.linux.misc...
> I utilize /dev/shm as temporary directory for some applications.
> However, even though I set the permissions to 1777 at startup, they
> seem to change later. 't' permission is lost, and this results that my
> applications cannot write to it when they run as users other than
> root. I've come with a simple workaround, a cron job that resets the
> permissions every minute.
Every minute? I should think that only once after boot-up would be
sufficient.
> But this is not satisfying.
>
> So I'd like to ask why this happens, and how to solve it. I use CentOS
> 5.8 x86.
Considering that /dev is entirely managed by udev now, you should look
in /udev/rules.d for clues, and that is also where you can specify
permissions.
--
= Aragorn =
(registered GNU/Linux user #223157)
following to comp.os.linux.misc...
> I utilize /dev/shm as temporary directory for some applications.
> However, even though I set the permissions to 1777 at startup, they
> seem to change later. 't' permission is lost, and this results that my
> applications cannot write to it when they run as users other than
> root. I've come with a simple workaround, a cron job that resets the
> permissions every minute.
sufficient.
> But this is not satisfying.
>
> So I'd like to ask why this happens, and how to solve it. I use CentOS
> 5.8 x86.
in /udev/rules.d for clues, and that is also where you can specify
permissions.
--
= Aragorn =
(registered GNU/Linux user #223157)
The Natural Philosopher
Sep 25, 2012, 10:31:29 AM9/25/12
to
But nothing exists there concerning this on my system.
This may be helpful:
http://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html
in particular using fstab to mount shm with different permissions from
the default.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
Lew Pitcher
Sep 25, 2012, 10:34:24 AM9/25/12
to
On Tuesday 25 September 2012 03:41, in comp.os.linux.misc,
allocate shared memory blocks; if you fill /dev/shm up with data other
than "shared memory", there might not be enough space for the shared memory
API to do it's work in.
If you use /dev/shm because it is a "tmpfs", allocated out of swap space,
you /could/ just mount another "tmpfs" under another mountpoint (i.e. /tmp
as a tmpfs) and get the same "temporary space" benefit, without impacting
the shared memory API.
> However, even though I set the permissions to 1777 at startup, they seem
> to change later. 't' permission is lost, and this results that my
> applications cannot write to it when they run as users other than root.
That's not a good sign. Aragorn has a good suggestion about checking your
udev rules to see what's up. However, since udev isn't the only thing that
can affect the /dev tree (and especially /dev/shm), you should also inspect
all those applications that you point at /dev/shm to see if any
a) have root access, and
b) change the permissions of their working directories
This may be easier to do as a negative test; create a different tmpfs tree,
and start moving apps to it. With each app moved, check to see if
the /dev/shm permissions still change. When you find that the permissions
stop changing from the original "sticky-bit set" values, you know that
you've moved the "bad" app to the other tmpfs tree.
By bouncing apps between the two trees, you can isolate the app that changes
the sticky bit.
> I've come with a simple workaround, a cron job that resets the
> permissions every minute. But this is not satisfying.
Agreed. That's not satisfying at all.
> So I'd like to ask why this happens, and how to solve it. I use CentOS
> 5.8 x86.
This happens because some euid root app chmods it's directories to values
that don't include the sticky bit. And, that /may be/ because they aren't
running with/in the correct directory (i.e. they shouldn't run in or with a
directory that requires the sticky bit set).
> Thanks all
HTH
--
Lew Pitcher
"In Skills, We Trust"
fesa...@gmail.com wrote:
> Hi all,
>
> I utilize /dev/shm as temporary directory for some applications.
That's not the best of ideas. The BSD "shared memory" APIs use /dev/shm to
> Hi all,
>
> I utilize /dev/shm as temporary directory for some applications.
allocate shared memory blocks; if you fill /dev/shm up with data other
than "shared memory", there might not be enough space for the shared memory
API to do it's work in.
If you use /dev/shm because it is a "tmpfs", allocated out of swap space,
you /could/ just mount another "tmpfs" under another mountpoint (i.e. /tmp
as a tmpfs) and get the same "temporary space" benefit, without impacting
the shared memory API.
> However, even though I set the permissions to 1777 at startup, they seem
> to change later. 't' permission is lost, and this results that my
> applications cannot write to it when they run as users other than root.
udev rules to see what's up. However, since udev isn't the only thing that
can affect the /dev tree (and especially /dev/shm), you should also inspect
all those applications that you point at /dev/shm to see if any
a) have root access, and
b) change the permissions of their working directories
This may be easier to do as a negative test; create a different tmpfs tree,
and start moving apps to it. With each app moved, check to see if
the /dev/shm permissions still change. When you find that the permissions
stop changing from the original "sticky-bit set" values, you know that
you've moved the "bad" app to the other tmpfs tree.
By bouncing apps between the two trees, you can isolate the app that changes
the sticky bit.
> I've come with a simple workaround, a cron job that resets the
> permissions every minute. But this is not satisfying.
> So I'd like to ask why this happens, and how to solve it. I use CentOS
> 5.8 x86.
that don't include the sticky bit. And, that /may be/ because they aren't
running with/in the correct directory (i.e. they shouldn't run in or with a
directory that requires the sticky bit set).
> Thanks all
HTH
--
Lew Pitcher
"In Skills, We Trust"
0 new messages