SUMMARY: ENOSYS on lofs /dev/null device

Sorry for the delay in summarising this question.

It appears that this doesn't work.  Loopback mounting of a single device
node does not provide a mount of the real device node, but some other device
node as specified by it's major/minor device numbers.

The intention of doing this was to have a way of making my chroot jail
nosuid and still provide very strict device access.  I have worked around
this until I find out if this will ever be supported by creating a superset
of devices but placing them outside of the chroot jail on a suid filesystem
and then loopback mounting the directory (suid) onto /dev in the chroot
jail.

Thanks for the response from Casper Dik:

>>> Ah, uhm.  Interesting question.  I would expect it should work
>>> properly; don't know why it should fail.

regards,

David.

----- Original Message -----
From: "Dave Leach" <david@healthinsite.gov.au>
To: <sunmanagers@sunmanagers.org>
Sent: Friday, June 07, 2002 1:47 PM
Subject: ENOSYS on lofs /dev/null device


> H all,
>
> As noone has responded to the original question... It seems that loopback
> mounting character devices is either broken or never meant to work?
>
> The major/minors of the devices are nothing like the actual device.. and
> attempts to operate on them (open for writing is the one for me, ie >
> /dev/null) fail with ENOSYS.  I just can't find anything that says you
> shouldn't be able to do it.
>
> Anyone got any ideas?
>
> I'll summarise (if I get any answers :-)
>
> dave.
> ----- Original Message -----
> From: "Dave Leach" <david@healthinsite.gov.au>
> To: <sunmanagers@sunmanagers.org>
> Sent: Wednesday, May 29, 2002 12:38 PM
> Subject: Followup: Re: NOSUID mount option kills devices in a chroot
>
>
> > Hmm..
> >
> > I've been thinking about this.. and I guess it's a 'good thing' that you
> > can't access devices on a nosuid mounted filesystem, and that loopback
> > mounting is possibly a nice way of controlling which devices you want
the
> > chroot envinronment to be able to access (eg other character devices
such
> as
> > /dev/null)
> >
> > So, I'll change my question below, to:
> >
> > Q.  Is there a reason why it's bad to loopback mount devices into a
chroot
> > jail?
> >
> > Again, I'll summarise answers.
> >
> > thanks,
> >
> > David.
> > ----- Original Message -----
> > From: "Dave Leach" <david@healthinsite.gov.au>
> > To: <sunmanagers@sunmanagers.org>
> > Cc: <duprec@scorec.rpi.edu>
> > Sent: Wednesday, May 29, 2002 11:46 AM
> > Subject: NOSUID mount option kills devices in a chroot
> >
> >
> > > hi all...
> > >
> > > I've been having some problems with java (jdk1.3)+chroot+nosuid
segv'ing
> > on
> > > Solaris 8 (sparc).  A review of the truss output uncovered that the
> > problem
> > > was due to java trying to open /dev/zero (which exists):
> > >
> > > 9189:   open("/dev/zero", O_RDWR)                       Err#6 ENXIO
> > >
> > > In fact, java segv's if it fails to open the device regardless of the
> > Error
> > > returned eg:
> > >
> > > 10453:  open("/dev/zero", O_RDWR)                      Err#2 ENOENT
> > >
> > > Looking back through the sunmanagers and focus-sun mail archives I
> noticed
> > > that someone had the same problem with with named-xfer.
> > > http://www.sunmanagers.org/pipermail/sunmanagers/2001-June/003951.html
> > >
> > > It appears as though the problem for me (and the named-xfer problem)
is
> > > highlighted in mount(2):
> > >
> > >      MS_NOSUID
> > >            This option prevents programs  taht  are  marked  set-
> > >            user-ID or set-group-ID from executing (see chmod(1)).
> > >            It also causes open(2) to return ENXIO when attempting
> > >            to open block or character special files.
> > >
> > >  mount_ufs and friends (1M) do not mention this however.
> > >
> > > I really don't want to mount my chroot jail filesystem suid, but it
> seems
> > > that I'm going to have to if I want to be able to run java in it.
> > >
> > > I can make it work, by loopback mounting /dev/zero into the chroot
jail,
> > but
> > > see this as ugly?  Does anyone see any reason why this is particularly
> > bad,
> > > and does anyone know of a better workaround for this?
> > >
> > > Thanks - will summarise.
> > >
> > > dave.
> > > _______________________________________________
> > > sunmanagers mailing list
> > > sunmanagers@sunmanagers.org
> > > http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers