From: Paul Menage <pmenage@ensim.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] User chroot
Date: Tue, 26 Jun 2001 17:37:01 -0700 [thread overview]
Message-ID: <E15F3KH-0003fd-00@pmenage-dt.ensim.com> (raw)
In-Reply-To: <0C01A29FBAE24448A792F5C68F5EA47D1205FB@nasdaq.ms.ensim.com>
In article <0C01A29FBAE24448A792F5C68F5EA47D1205FB@nasdaq.ms.ensim.com>,
you write:
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot. In other
>words, it's all pain, no gain.
>
It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP server) that wanted to be absolutely sure that neither it
nor any of its libraries were being tricked into following a bogus
symlink, or a "/../" in a passed filename. After initialisation, the
daemon could chroot() into its data directory, and safely only serve
the set of files within that directory hierarchy.
This could be regarded as the wrong way to solve such a problem, but
this kind of bug seems to be occurring often enough on BugTraq that it
might be useful if you don't have the resources to do a full security
audit on your program (or if the source to some of your libraries
isn't available).
Paul
next parent reply other threads:[~2001-06-27 0:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0C01A29FBAE24448A792F5C68F5EA47D1205FB@nasdaq.ms.ensim.com>
2001-06-27 0:37 ` Paul Menage [this message]
2001-06-27 0:45 ` H. Peter Anvin
2001-06-27 0:53 ` David Wagner
2001-06-27 0:51 ` David Wagner
2001-06-27 1:08 ` Mohammad A. Haque
2001-06-27 1:24 ` Paul Menage
2001-06-27 1:40 ` Alexander Viro
2001-06-27 2:17 ` Paul Menage
2001-06-27 6:35 ` Kai Henningsen
2001-06-27 7:19 ` Chris Wedgwood
2001-06-27 7:43 ` Alexander Viro
2001-06-27 4:39 ` David Wagner
2001-06-27 23:11 Andries.Brouwer
-- strict thread matches above, loose matches on Subject: below --
2001-06-27 13:57 Jesse Pollard
2001-06-27 17:42 ` David Wagner
2001-06-26 23:45 Jorgen Cederlof
2001-06-26 23:46 ` H. Peter Anvin
2001-06-27 0:48 ` David Wagner
2001-06-27 12:56 ` Marco Colombo
2001-06-27 13:56 ` Admin Mailing Lists
2001-06-27 3:32 ` Albert D. Cahalan
2001-06-27 4:24 ` H. Peter Anvin
2001-06-27 20:55 ` Albert D. Cahalan
2001-06-27 21:03 ` H. Peter Anvin
2001-06-27 21:19 ` Albert D. Cahalan
2001-06-28 7:47 ` Sean Hunter
2001-06-28 18:25 ` Albert D. Cahalan
2001-06-27 6:31 ` Kai Henningsen
2001-06-27 15:39 ` Marcus Sundberg
2001-06-27 17:55 ` Jorgen Cederlof
2001-06-27 6:37 ` Kai Henningsen
2001-06-27 18:14 ` H. Peter Anvin
2001-06-28 6:54 ` Kai Henningsen
2001-06-29 13:46 ` Jorgen Cederlof
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=E15F3KH-0003fd-00@pmenage-dt.ensim.com \
--to=pmenage@ensim.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®