Your message dated Sat, 7 Apr 2012 13:19:58 +0100
with message-id <[email protected]>
and subject line Re: Bug#390184: [Pkg-sysvinit-devel] Bug#390184: initscripts:
please limit the size of /lib/init/rw
has caused the Debian Bug report #390184,
regarding initscripts: please limit the size of /lib/init/rw
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
390184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390184
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: initscripts
Version: 2.86.ds1-27
Severity: wishlist
Hello,
could you please limit the size of /lib/init/rw to something reasonable?
The current version should be okay regarding DoSes because of the access
rights, however, I'm not sure how it behaves on non-overcommitting
kernels.
I personally think that something around 100k should suffice, but if
you like to have it somehow dynamic, I attached a small sample patch
which limits the size to one tenth of available memory. I moved the
section which mounts /lib/init/rw down a bit to access /proc/meminfo.
The patch works on 2.4 and 2.6 and it falls automatically back to the
defaults if /proc/meminfo should not be available or cannot be parsed.
regards
Mario
--
There is nothing more deceptive than an obvious fact.
-- Sherlock Holmes by Arthur Conan Doyle
--- /etc/init.d/mountkernfs.sh 2006-09-25 10:42:07.000000000 +0200
+++ mountkernfs.sh 2006-09-29 18:22:10.000000000 +0200
@@ -21,15 +21,6 @@
do_start () {
#
- # Get some writable area available before the root is checked
- # and remounted.
- #
- RW_OPT=
- [ "${RW_SIZE:=$TMPFS_SIZE}" ] && RW_OPT=",size=$RW_SIZE"
- domount tmpfs "" /lib/init/rw tmpfs -omode=0755,nosuid$RW_OPT
- touch /lib/init/rw/.ramfs
-
- #
# Mount proc filesystem on /proc
#
domount proc "" /proc proc -onodev,noexec,nosuid
@@ -43,6 +34,24 @@
domount sysfs "" /sys sysfs -onodev,noexec,nosuid
fi
+ #
+ # Get some writable area available before the root is checked
+ # and remounted.
+ #
+ RW_OPT=
+ if [ "${RW_SIZE:=$TMPFS_SIZE}" ]; then
+ RW_OPT=",size=$RW_SIZE"
+ else
+ while read line total rest; do
+ if [ "$line" = "Mem:" ]; then
+ RW_OPT=",size=$(($total / 10))"
+ break;
+ fi
+ done < /proc/meminfo
+ fi
+ domount tmpfs "" /lib/init/rw tmpfs -omode=0755,nosuid$RW_OPT
+ touch /lib/init/rw/.ramfs
+
# Mount /var/run and /var/lock as tmpfs if enabled
if [ yes = "$RAMRUN" ] ; then
RUN_OPT=
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Version: 2.88dsf-13.3
On Fri, Sep 29, 2006 at 07:39:26PM +0200, Petter Reinholdtsen wrote:
> [Mario Holbe]
> > I personally think that something around 100k should suffice, but if
> > you like to have it somehow dynamic, I attached a small sample patch
> > which limits the size to one tenth of available memory.
>
> Thank you for the patch. If we want dosemu and user-mode-linux to
> stop using /dev/shm/ to store their mmaped files, and instead use
> /lib/init/rw/ or similar, the size will have to be a lot higher than
> 100k.
>
> One idea I am considering is to make /dev/shm/ a symlink or bind-mount
> to a subdirectory /lib/init/rw/shm/, and thus only have one tmpfs file
> system by default. I also consider modifying the RANLOCK and RANRUN
> code to behave similarly, either symlink or bind-mount to
> /lib/init/rw/.
Now that we have /run, this is now a reality. Though it's
/run/shm rather than /lib/init/rw/shm now /lib/init/rw is gone.
We now also have separate configurable limits for each tmpfs
mounted, including separate limits for /run and /run/shm. The
limit for /run is indeed 10% of core memory as was initially
suggested (which replaced /lib/init/rw).
I'm closing the bug because, although it has taken 5 years, we
now do implement the behaviour requested, even though the
filesystem locations have changed.
> > I moved the section which mounts /lib/init/rw down a bit to access
> > /proc/meminfo.
>
> I decided to mount it before /proc/, because we plan to modify mount
> to use a file in /lib/init/rw/ instead of /etc/mtab to get rid of a
> lot of complexity handling /etc/mtab. I'm not sure if we want to move
> it after /proc/ because of this.
This is also a non-issue now we eliminated mtab.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--- End Message ---
_______________________________________________
Pkg-sysvinit-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
