public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox