[Pkg-sysvinit-devel] Re: [Pkg-uml-pkgs] How is user-mode-linux using /dev/shm/?

[Mattia Dongili]

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!