From: Mattia D. <mal...@li...> - 2006-09-28 19:48:27
|
Thanks Petter for writing, I was going to followup to the sysvinit bug :) I'm Cc-ing upstream too. On Thu, Sep 28, 2006 at 08:14:32PM +0200, Petter Reinholdtsen wrote: > > Hi > > I am one of the sysvinit maintainers. Recently we changed the mount > options of /dev/shm/, and got a bug report about uml refusing to start > (#386945). Because of this, I am curious how uml uses /dev/shm/. Is > it using the shm-functions in glibc, or something else? Please > explain how it work. I don't think it uses shm* functions, as far as I can tell the /dev/shm location is sensible to $TMP, $TEMP or $TEMPDIR, thus changing one of them to a different location goes farther than what's reported in the bureport: $ TMPDIR=./TMP linux ubd0=rootfs_debian-sid.172.20.0.20 ubd1=swap-172.20.0.20 eth0=tuntap,,,172.20.0.19 umid=debian mem=128 Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in ./TMP/...OK Checking for the skas3 patch in the host: - /proc/mm...not found - PTRACE_FAULTINFO...not found - PTRACE_LDT...not found UML running in SKAS0 mode Mapping memory: Cannot allocate memory Don't know now, it's maybe easy to fix, there's a nice global variable set to "/dev/shm" in arch/um/os-Linux/mem.c and UML uses mkstemp() to create files. > To make some writable tmpfs available to those in need of such system, > and to avoid using /dev/shm/ which is reserved for the shm-functions, > I just uploaded sysvinit version 2.86.ds1-26. It will mount a tmpfs > on /lib/init/rw/ that can be used instead. If /lib/init/rw/.ramfs > exist, that mount point is a tmpfs. I'm not sure if this last change > will make it into Etch or not, but I hope so, to solve any problems > with packages previously using /dev/shm/ as a generic tmpfs file > system. Well, I'd actually prefer if you could remove the noexec flag from /dev/shm. I understand the security reasons given in the bugreport but I'd prefer avoid having to deal with one more Debian-only (is it?) thing given the soon to come general freeze. Thanks -- mattia :wq! |
From: Petter R. <pe...@hu...> - 2006-09-28 20:19:50
|
[Mattia Dongili] > Well, I'd actually prefer if you could remove the noexec flag from > /dev/shm. I understand the security reasons given in the bugreport > but I'd prefer avoid having to deal with one more Debian-only (is > it?) thing given the soon to come general freeze. I am considering this for etch only, and to reinsert it once etch is released. I suspect it is better to break uml, dosemu and others misusing /dev/shm/ early in the etch+1 release cycle instead of late in the etch cycle. But I might be too late, as base and sysvinit is already frozen, according to the email from Andreas. :( We will have to discuss it with the release managers, I guess. Friendly, -- Petter Reinholdtsen |
From: Mattia D. <mal...@li...> - 2006-09-29 07:17:21
|
On Thu, September 28, 2006 10:19 pm, Petter Reinholdtsen said: > [Mattia Dongili] >> Well, I'd actually prefer if you could remove the noexec flag from >> /dev/shm. I understand the security reasons given in the bugreport >> but I'd prefer avoid having to deal with one more Debian-only (is >> it?) thing given the soon to come general freeze. > > I am considering this for etch only, and to reinsert it once etch is > released. I suspect it is better to break uml, dosemu and others > misusing /dev/shm/ early in the etch+1 release cycle instead of late > in the etch cycle. absolutely seconded. > But I might be too late, as base and sysvinit is already frozen, > according to the email from Andreas. :( We will have to discuss it > with the release managers, I guess. I can still file a critical bug because sysvinit "breaks unrelated SW" :) Let's submit the question to d-release then. --=20 mattia :wq! |
From: Jeff D. <jd...@ad...> - 2006-09-28 21:54:18
|
On Thu, Sep 28, 2006 at 09:47:27PM +0200, Mattia Dongili wrote: > On Thu, Sep 28, 2006 at 08:14:32PM +0200, Petter Reinholdtsen wrote: > > To make some writable tmpfs available to those in need of such system, > > and to avoid using /dev/shm/ which is reserved for the shm-functions, > > I just uploaded sysvinit version 2.86.ds1-26. It will mount a tmpfs > > on /lib/init/rw/ that can be used instead. If /lib/init/rw/.ramfs > > exist, that mount point is a tmpfs. I'm not sure if this last change > > will make it into Etch or not, but I hope so, to solve any problems > > with packages previously using /dev/shm/ as a generic tmpfs file > > system. > > Well, I'd actually prefer if you could remove the noexec flag from > /dev/shm. I understand the security reasons given in the bugreport but > I'd prefer avoid having to deal with one more Debian-only (is it?) > thing given the soon to come general freeze. UML needs a non-noexec place to keep a file that will be used as its physical memory. A tmpfs mount is greatly preferred for performance reasons as well as tmpfs being the only filesystem supporting MADV_REMOVE, which is used for memory hotplug. Jeff |
From: Mattia D. <mal...@li...> - 2006-09-29 17:51:43
|
On Thu, Sep 28, 2006 at 05:51:43PM -0400, Jeff Dike wrote: > On Thu, Sep 28, 2006 at 09:47:27PM +0200, Mattia Dongili wrote: > > On Thu, Sep 28, 2006 at 08:14:32PM +0200, Petter Reinholdtsen wrote: > > > To make some writable tmpfs available to those in need of such system, > > > and to avoid using /dev/shm/ which is reserved for the shm-functions, > > > I just uploaded sysvinit version 2.86.ds1-26. It will mount a tmpfs > > > on /lib/init/rw/ that can be used instead. If /lib/init/rw/.ramfs > > > exist, that mount point is a tmpfs. I'm not sure if this last change > > > will make it into Etch or not, but I hope so, to solve any problems > > > with packages previously using /dev/shm/ as a generic tmpfs file > > > system. > > > > Well, I'd actually prefer if you could remove the noexec flag from > > /dev/shm. I understand the security reasons given in the bugreport but > > I'd prefer avoid having to deal with one more Debian-only (is it?) > > thing given the soon to come general freeze. > > UML needs a non-noexec place to keep a file that will be used as its > physical memory. A tmpfs mount is greatly preferred for performance > reasons as well as tmpfs being the only filesystem supporting > MADV_REMOVE, which is used for memory hotplug. Thinking of a Debian only fix for the above, does simply playing with default_tmpdir in arch/um/os-Linux/mem.c (probably in which_tmpdir()) suffice to use /lib/init/rw/.ramfs as default? (Yes I should try it... will try to find some time next week) Thanks -- mattia :wq! |
From: Blaisorblade <bla...@ya...> - 2006-09-30 12:37:24
|
On Friday 29 September 2006 19:46, Mattia Dongili wrote: > On Thu, Sep 28, 2006 at 05:51:43PM -0400, Jeff Dike wrote: > > On Thu, Sep 28, 2006 at 09:47:27PM +0200, Mattia Dongili wrote: > > > On Thu, Sep 28, 2006 at 08:14:32PM +0200, Petter Reinholdtsen wrote: > > > > To make some writable tmpfs available to those in need of such > > > > system, and to avoid using /dev/shm/ which is reserved for the > > > > shm-functions, I just uploaded sysvinit version 2.86.ds1-26. It will > > > > mount a tmpfs on /lib/init/rw/ that can be used instead. If > > > > /lib/init/rw/.ramfs exist, that mount point is a tmpfs. I'm not sure > > > > if this last change will make it into Etch or not, but I hope so, to > > > > solve any problems with packages previously using /dev/shm/ as a > > > > generic tmpfs file system. > > > > > > Well, I'd actually prefer if you could remove the noexec flag from > > > /dev/shm. I understand the security reasons given in the bugreport but > > > I'd prefer avoid having to deal with one more Debian-only (is it?) > > > thing given the soon to come general freeze. > > > > UML needs a non-noexec place to keep a file that will be used as its > > physical memory. A tmpfs mount is greatly preferred for performance > > reasons as well as tmpfs being the only filesystem supporting > > MADV_REMOVE, which is used for memory hotplug. > > Thinking of a Debian only fix for the above, does simply playing with > default_tmpdir in arch/um/os-Linux/mem.c (probably in which_tmpdir()) > suffice to use /lib/init/rw/.ramfs as default? Is it world-writable with the sticky bit set as /tmp and /dev/shm? I do not know -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Jeff D. <jd...@ad...> - 2006-09-29 19:01:08
|
On Fri, Sep 29, 2006 at 07:46:01PM +0200, Mattia Dongili wrote: > Thinking of a Debian only fix for the above, does simply playing with > default_tmpdir in arch/um/os-Linux/mem.c (probably in which_tmpdir()) > suffice to use /lib/init/rw/.ramfs as default? > > (Yes I should try it... will try to find some time next week) What difference would this make? You still have some world-writable place not mounted noexec that nasty people could try to take advantage of. You're just changing the name of that place. Jeff |
From: Henrique de M. H. <hm...@de...> - 2006-09-29 19:52:27
|
On Fri, 29 Sep 2006, Jeff Dike wrote: > On Fri, Sep 29, 2006 at 07:46:01PM +0200, Mattia Dongili wrote: > > Thinking of a Debian only fix for the above, does simply playing with > > default_tmpdir in arch/um/os-Linux/mem.c (probably in which_tmpdir()) > > suffice to use /lib/init/rw/.ramfs as default? > > > > (Yes I should try it... will try to find some time next week) > > What difference would this make? You still have some world-writable place > not mounted noexec that nasty people could try to take advantage of. You're > just changing the name of that place. It does not intrude in SYSV shm namespace anymore. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh |
From: Blaisorblade <bla...@ya...> - 2006-09-30 12:38:48
|
On Thursday 28 September 2006 21:47, Mattia Dongili wrote: > Thanks Petter for writing, > I was going to followup to the sysvinit bug :) > > I'm Cc-ing upstream too. > I don't think it uses shm* functions, as far as I can tell the /dev/shm > location is sensible to $TMP, $TEMP or $TEMPDIR, thus changing one of > them to a different location goes farther than what's reported in the > bureport: > $ TMPDIR=./TMP linux ubd0=rootfs_debian-sid.172.20.0.20 > ubd1=swap-172.20.0.20 eth0=tuntap,,,172.20.0.19 umid=debian mem=128 > Checking that ptrace can change system call numbers...OK > Checking syscall emulation patch for ptrace...OK > Checking advanced syscall emulation patch for ptrace...OK > Checking for tmpfs mount on /dev/shm...OK > Checking PROT_EXEC mmap in ./TMP/...OK > Checking for the skas3 patch in the host: > - /proc/mm...not found > - PTRACE_FAULTINFO...not found > - PTRACE_LDT...not found > UML running in SKAS0 mode > Mapping memory: Cannot allocate memory There is probably some additional bug here, it should be easy to fix. > Don't know now, it's maybe easy to fix, there's a nice global variable > set to "/dev/shm" in arch/um/os-Linux/mem.c and UML uses mkstemp() to > create files. > > > To make some writable tmpfs available to those in need of such system, > > and to avoid using /dev/shm/ which is reserved for the shm-functions, > > I just uploaded sysvinit version 2.86.ds1-26. It will mount a tmpfs > > on /lib/init/rw/ that can be used instead. If /lib/init/rw/.ramfs > > exist, that mount point is a tmpfs. I'm not sure if this last change > > will make it into Etch or not, but I hope so, to solve any problems > > with packages previously using /dev/shm/ as a generic tmpfs file > > system. > > Well, I'd actually prefer if you could remove the noexec flag from > /dev/shm. I understand the security reasons given in the bugreport but > I'd prefer avoid having to deal with one more Debian-only (is it?) It is not - it can happen on Gentoo too (actually, the issue there is simply that the manuals _recommend_ to use noexec for /dev/shm). > thing given the soon to come general freeze. As Jeff Dike explained, we just need to use an executable tmpfs mount. For a long time, we used /tmp and _suggested_ people to use tmpfs for it, or to use it elsewhere and point TMP there. And quite frankly, it would be nicer to make that a default (i.e. if /tmp is automatically a tmpfs mount, switching back there would be nice). In 2.4 days, using tmpfs for /tmp was bad for one issue: you could not do a loopback mount from tmpfs, and this broke mkinitrd; but that has been solved since then, for 2.6 at least. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |