All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nuno Silva <nuno.silva@vgertech.com>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Jochen Bern <bern@ti.uni-trier.de>, linux-kernel@vger.kernel.org
Subject: Re: procfs and chroot() ... ?
Date: Wed, 15 Sep 2004 04:41:20 +0100	[thread overview]
Message-ID: <4147B9E0.1090306@vgertech.com> (raw)
In-Reply-To: <20040914025300.GG23987@parcelfarce.linux.theplanet.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

viro@parcelfarce.linux.theplanet.co.uk wrote:
| On Tue, Sep 14, 2004 at 03:30:29AM +0200, Jochen Bern wrote:
|
|>I'm trying to chroot() a server that needs to read one readonly pseudo
|>file from /proc . I tried to pinpoint my options to do so ...
|>
|>-- The alternative to accessing this one pseudo file would be to grant
|>   the server access to /dev/kmem ... NOT ... ANY ... BETTER!! 8-}
|>-- Mounting two procfs instances (one normal, one inside the chroot())
|>   and setting restrictive permissions on the latter makes identical
|>   changes to the former. (I assume that'ld be the same for ACLs?)
|>-- Deploying SELinux ... will have to do a good deal of reading to
|>   even find out what'ld be involved in that ...
|>-- Mounting a "second" procfs, chroot()ing into the exact subdir the
|>   file is in, and mounting non-procfs stuff (like the etc dir with the
|>   configs) *over* the sub-subdirs (ARGH!) would *happen* to rid me of
|>   all *writable* pseudo files, but still provide read access to way
|>   more info that I'ld want to provide to the server ...
|>(- I'll try to Use The Source (tm) so that the server will not close the
|>   pseudo file, and does the chroot() itself after opening it, but let's
|>   assume for the sake of the argument that I won't succeed in that.)
|
|
| Egads...
|
| mount --bind /proc/whatever/the/fsck/you/want \
| 	/home/jail/wherever/the/fsck/you/want/to/see/it
|
| (assuming that jail is in /home/jail and "mountpoint" exists).

Jochen,
you can also --bind only one file. But you must create the file first:

# mkdir /var/jails/jail1/proc
# touch /var/jails/jail1/proc/cpuinfo
# mount --bind /proc/cpuinfo /var/jails/jail1/proc/cpuinfo

Regards,
Nuno Silva
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBR7ngOPig54MP17wRAuL9AKCnrrHSuAxGZTz0P53JthkMIF9wHgCeOMam
kv9QDqkpnAqB+XzVcTKNyIo=
=lJiN
-----END PGP SIGNATURE-----

      reply	other threads:[~2004-09-15  3:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-14  1:30 procfs and chroot() ... ? Jochen Bern
2004-09-14  2:53 ` viro
2004-09-15  3:41   ` Nuno Silva [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4147B9E0.1090306@vgertech.com \
    --to=nuno.silva@vgertech.com \
    --cc=bern@ti.uni-trier.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.