|
Home > Archive > Debian Developers > September 2007 > How to detect if inside a buildd chroot
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to detect if inside a buildd chroot
|
|
| Sebastian Dröge 2007-09-25, 7:33 am |
| Hi,
does somebody know about a solution to check whether one runs in a
buildd chroot or not? I need this to prevent hal from starting in buildd
chroots (via invoke-rc.d from postinst) as it breaks there because of
several reasons, including no /sys mounted.
This currently makes it impossible to have a library package depend on
something that depends on hal although this would be correct in a few
cases.
Thanks
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nikita V. Youshchenko 2007-09-25, 7:33 am |
| Sebastian Dr?ge wrote:
> Hi,
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
Maybe better to check for features that hal depends on.
E.g. not start if /sys is not mounted.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2007-09-25, 7:33 am |
| | |
| Marco d'Itri 2007-09-25, 7:33 am |
| On Sep 25, Sebastian Dröge <slomo@circular-chaos.org> wrote:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
Look at the maintainer scripts of the udev package.
--
ciao,
Marco
| |
| Jonas Meurer 2007-09-25, 7:33 am |
| On 25/09/2007 Sebastian Dröge wrote:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
I tought that this should be handled by invoke-rc.d itself. The manpage
states that:
invoke-rc.d introduces the concept of a policy layer which is
used to verify if an init script should be run or not, or if
something else should be done instead. This layer has various
uses, the most immediate ones being avoiding that package
upgrades start daemons out-of-runlevel, and that a package
starts or stops daemons while inside a chroot jail.
So my assumption was that invoke-rc.d detects if it's invoked inside a
chroot, and doesn't start the service in that case.
greetings,
jonas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Simon Richter 2007-09-25, 7:33 am |
| Hi,
Sebastian Dröge schrieb:
> does somebody know about a solution to check whether one runs in a
> buildd chroot or not? I need this to prevent hal from starting in buildd
> chroots (via invoke-rc.d from postinst) as it breaks there because of
> several reasons, including no /sys mounted.
My chroots have /proc and /sys mounted, but I'd still be grateful if hal
didn't start.
Would it make sense to demote the dependency on the hal daemon to a
Recommends (after all, the hal "client" library should deal with the
daemon not running anyway)?
Simon
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sebastian Dröge 2007-09-25, 7:33 am |
| Am Dienstag, den 25.09.2007, 11:35 +0200 schrieb Marco d'Itri:
> On Sep 25, Sebastian Dröge <slomo@circular-chaos.org> wrote:
>
> Look at the maintainer scripts of the udev package.
Thanks, I'll take a look at it... also trying to check all prequisites
that hal needs in the init script before launching it might be a
solution.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sebastian Dröge 2007-09-25, 7:33 am |
| Am Dienstag, den 25.09.2007, 11:55 +0200 schrieb Simon Richter:
> Hi,
>
> Sebastian Dröge schrieb:
>
>
> My chroots have /proc and /sys mounted, but I'd still be grateful if hal
> didn't start.
>
> Would it make sense to demote the dependency on the hal daemon to a
> Recommends (after all, the hal "client" library should deal with the
> daemon not running anyway)?
In one of the cases I found this won't be correct:
gnome-mount depends on hal as it doesn't work at all without hal.
libnautilus-burn should depend on gnome-mount as it can't do some stuff
if gnome-mount is not available. If this is a recommends only, people
that don't install recommends have a unusable library lying around.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sebastian Dröge 2007-09-25, 7:33 am |
| Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer:
> On 25/09/2007 Sebastian Dröge wrote:
>
> I tought that this should be handled by invoke-rc.d itself. The manpage
> states that:
>
> invoke-rc.d introduces the concept of a policy layer which is
> used to verify if an init script should be run or not, or if
> something else should be done instead. This layer has various
> uses, the most immediate ones being avoiding that package
> upgrades start daemons out-of-runlevel, and that a package
> starts or stops daemons while inside a chroot jail.
>
>
> So my assumption was that invoke-rc.d detects if it's invoked inside a
> chroot, and doesn't start the service in that case.
AFAIK this only happens if specified in some config file that daemons
shouldn't be started. Whatever, although hal is invoked by invoke-rc.d
it is started in the buildd chroots. :/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Simon Richter 2007-09-25, 7:33 am |
| Hi,
Sebastian Dröge wrote:
[vbcol=seagreen]
> gnome-mount depends on hal as it doesn't work at all without hal.
Well, gnome-mount should never be installed on an autobuilder IMO.
> libnautilus-burn should depend on gnome-mount as it can't do some stuff
> if gnome-mount is not available. If this is a recommends only, people
> that don't install recommends have a unusable library lying around.
That sounds like "recommends", TBH. The fact that apt used to not
install Recommends by default has led to way too stringent
relationships; I don't see a problem with packages that are largely
unusable without a recommended package as long as they handle the
situation gracefully.
Simon
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sebastian Dröge 2007-09-25, 7:33 am |
| Am Dienstag, den 25.09.2007, 12:23 +0200 schrieb Simon Richter:
> Hi,
>
> Sebastian Dröge wrote:
>
>
>
> Well, gnome-mount should never be installed on an autobuilder IMO.
>
>
> That sounds like "recommends", TBH. The fact that apt used to not
> install Recommends by default has led to way too stringent
> relationships; I don't see a problem with packages that are largely
> unusable without a recommended package as long as they handle the
> situation gracefully.
Ok, but even if it is recommends, as apt install recommends by default
won't it be installed in the buildd chroots too?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Lars Wirzenius 2007-09-25, 7:33 am |
| ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti:
> Hi,
>
> Sebastian Dröge schrieb:
>
>
> My chroots have /proc and /sys mounted, but I'd still be grateful if hal
> didn't start.
Would policy-rc.d be helpful for this situation?
--
Don't use me as a bat in your fight; I might start hitting you instead
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Reinhard Tartler 2007-09-25, 7:33 am |
| tag 439389 help
stop
Sebastian Dröge <slomo@circular-chaos.org> writes:
>
> In one of the cases I found this won't be correct:
>
> gnome-mount depends on hal as it doesn't work at all without hal.
>
> libnautilus-burn should depend on gnome-mount as it can't do some stuff
> if gnome-mount is not available. If this is a recommends only, people
> that don't install recommends have a unusable library lying around.
I think this problem is similar to #439389 in xine-lib (RC, help
really appreciated):
- libxine1 only depends on libraries, that it really needs. This
leaves users that don't install the recommended packages in the
situation, that they cannot play their mp3/ogg/etc files.
- Promoting them to depends causes them to be installed in any case,
which is unwanted in special-use situations (think embedded or
special purpose multimedia center installations).
- leaving them as recommends causes xine frontends not only to build
faster (fewer dependencies to be installed), but also to build more
reliably (as you aren't affected by some potential library
transition, happened several times in the past.
In conclusion: I think we are facing a very similar problem, but we are
solving it differently: You prefer to not annoy users which don't
respect recommends, and I urge/force people to install recommends if
they want to have a usable frontend. Can we perhaps reach a broader
consensus on this type of decisions?
Ideally, we can clarify this in the Developers Reference.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Edward Allcutt 2007-09-25, 1:28 pm |
| On Tue, 2007-09-25 at 13:14 +0300, Lars Wirzenius wrote:
> ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti:
>
> Would policy-rc.d be helpful for this situation?
According to /usr/share/doc/sysv-rc/README.policy-rc.d all you need is
a /usr/sbin/policy-rc.d (inside the chroot) containing:
exit 101
Is there a reason the abovementioned isn't part of "standard" Debian
chroots such as those on buildds?
--
Edward Allcutt <ema29@srcf.ucam.org>
| |
| John Goerzen 2007-09-25, 1:28 pm |
| On Tue September 25 2007 5:03:32 am Sebastian Dr=C3=B6ge wrote:
>
> AFAIK this only happens if specified in some config file that daemons
> shouldn't be started. Whatever, although hal is invoked by invoke-rc.d
> it is started in the buildd chroots. :/
It is this whole problem that has caused me to never want to try to build=20
things in chroots -- the problem of installing things that mess with=20
daemons. I've had MTAs restarted, cron restarted, etc.
I don't really think that chroot is the appropriate tool for this. Why not=
=20
something more strongly isolated, such as vserver, OpenVZ, or even Xen or=20
UML for this?
=2D- John
| |
| Reinhard Tartler 2007-09-25, 1:28 pm |
| Sebastian Dröge <slomo@circular-chaos.org> writes:
>
> Ok, but even if it is recommends, as apt install recommends by default
> won't it be installed in the buildd chroots too?
I'd assume that the buildd maintainers will configure apt in a way that
it doesn't install recommends, but only depends. I don't know if this
has been discussed among the buildd maintainers, does anybody know a
contact adress for them as collective?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Reinhard Tartler 2007-09-25, 1:28 pm |
| John Goerzen <jgoerzen@complete.org> writes:
> It is this whole problem that has caused me to never want to try to build
> things in chroots -- the problem of installing things that mess with
> daemons. I've had MTAs restarted, cron restarted, etc.
Sounds like a bug (severity important) to me.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Lars Wirzenius 2007-09-25, 1:28 pm |
| ti, 2007-09-25 kello 08:18 -0500, John Goerzen kirjoitti:
> I don't really think that chroot is the appropriate tool for this.
> Why not
> something more strongly isolated, such as vserver, OpenVZ, or even Xen or
> UML for this?
If the chroot has a policy-rc.d that says not to start daemons, any
package that does so is buggy (possibly even RC buggy), and needs to be
fixed. Luckily, there's few such packages anymore.
--
Yet another quit message no-one will ever comment on.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2007-09-25, 1:28 pm |
| On Tue, 25 Sep 2007 08:18:39 -0500, John Goerzen <jgoerzen@complete.org> said:
> I don't really think that chroot is the appropriate tool for this.
> Why not something more strongly isolated, such as vserver, OpenVZ, or
> even Xen or UML for this?
I've always used an UML for this. I need to automate my
workflow a bit more -- there are two parts of building packages; one
set of operations run as root (build depends loading, and running
piuparts), and another set which is run as a user running perhaps under
fake root (the real build etc). I can use an @boot cron job to run
stuff; but I have not done so since specifying SELinux policy for this
is not gonna be fun (run as root in some security domain, and then
start a dpkg-buildpackage as root in the usr_t domain), and I have been
being lazy.
I already have a shell version of satisfy_builddeps, so all I
really need is to have the policy snippet, and I'll publish my building
in a SELinux uml/kvm virtual machine thing.
In my copious spare time, of course.
manoj
--
It's a naive, domestic operating system without any breeding, but I
think you'll be amused by its presumption.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2007-09-25, 1:28 pm |
| * Reinhard Tartler:
> - libxine1 only depends on libraries, that it really needs. This
> leaves users that don't install the recommended packages in the
> situation, that they cannot play their mp3/ogg/etc files.
I guess this will be a non-issue as soon as apt-get installs
recommends by default. Users who overide this will know what to do in
this situation.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| A Mennucc 2007-09-26, 1:27 pm |
| hi
It is all explained in
/usr/share/doc/sysv-rc/README.policy-rc.d
It seems that all you need to do is to create inside your chroot a
simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101'
for example with these two simple commands
$ echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d
$ chmod +x /usr/sbin/policy-rc.d
then invoke-rc.d becomes a no-op, it will not start or stop anything.
Unfortunately the docs are a bit incomprehensible to me .. it seems you
can do much complex stuff than that, but I cant help. You may want to
look into the package policyrcd-script-zg2 : they know their act.
a.
Sebastian Dr=C3=B6ge ha scritto:
> Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer:
ldd[vbcol=seagreen]
e[vbcol=seagreen]
>=20
> AFAIK this only happens if specified in some config file that daemons
> shouldn't be started. Whatever, although hal is invoked by invoke-rc.d
> it is started in the buildd chroots. :/
>=20
>=20
| |
| Mike Hommey 2007-09-26, 7:21 pm |
| On Wed, Sep 26, 2007 at 09:31:36PM +0100, Roger Leigh wrote:
> A Mennucc <mennucc1@debian.org> writes:
>
>
> I would very much prefer that all packages worked correctly inside a
> chroot without any admin intervention. If it's not appropriate to run
> inside a chroot, then the init script should IMHO detect that and not
> start/restart/stop the service.
The fact is, not all chroot are buildd chroots, and many chroots
actually do run services...
Mike
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2007-09-26, 7:21 pm |
| | |
| Tyler MacDonald 2007-09-26, 7:21 pm |
| Mike Hommey <mh@glandium.org> wrote:
>
> The fact is, not all chroot are buildd chroots, and many chroots
> actually do run services...
Yep... but I still find it a bit annoying that I have to override binaries
like start-stop-daemon or invoke-rc.d when building a chroot. I wish there
was a way to just set a flag that means "dpkg, don't start/stop any
services!"... instead I end up doing stuff like:
invoke="/usr/sbin/invoke-rc.d"
cdebootstrap -f "standard" "$SUITE" "$TARGET" "$MIRROR"
mount -t proc proc "$TARGET/proc"
$chroot "$TARGET" $aptitude update || throw
$chroot "$TARGET" /usr/sbin/dpkg-divert \
--add --rename --divert $invoke.orig $invoke || throw
ln -sf /bin/true "$TARGET/$invoke"
[bootstrap code...]
/bin/rm -f "$TARGET/$invoke"
$chroot "$TARGET" /usr/sbin/dpkg-divert \
--remove --rename --divert $invoke.orig $invoke || throw
umount "$TARGET/proc"
- Tyler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Lars Wirzenius 2007-09-26, 7:21 pm |
| ke, 2007-09-26 kello 13:49 -0700, Tyler MacDonald kirjoitti:
> Yep... but I still find it a bit annoying that I have to override
> binaries
> like start-stop-daemon or invoke-rc.d when building a chroot. I wish there
> was a way to just set a flag that means "dpkg, don't start/stop any
> services!"... instead I end up doing stuff like:
That shouldn't be necessary anymore. The policy-rc.d trick that has been
mentioned in this thread a couple of times should work fine. Here's the
code in piuparts which does it:
full_name = os.path.join(self.name, "usr/sbin/policy-rc.d")
create_file(full_name, "#!/bin/sh\nexit 101\n")
os.chmod(full_name, 0777)
--
Copyrights, patents, trademarks: not property, not rights, but
priviledges!
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony DeRobertis 2007-09-29, 7:28 am |
| Roger Leigh wrote:
> You can't reliably (or portably) check if you are in a chroot.
Hmm, if you're root you probably can. Something like this (completely
untested; probably doesn't even compile):
DIR *d;
int fd;
struct stat s1, s2;
mkdir("temp", 0700);
d = opendir("/");
fd = dirfd(d);
fstat(fd, &s1);
chroot("temp");
fchdir(fd);
stat("..", &s2);
if (s1.st_dev != s2.st_dev || s1.st_ino != s2.st_ino) {
/* we were in a chroot */
}
Actually, come to think of it, I wonder if stat'ing "/.." would work...
If it does, then you don't even need root.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Juan Céspedes 2007-09-29, 7:28 am |
| On 9/29/07, Anthony DeRobertis <anthony@derobert.net> wrote:
> Hmm, if you're root you probably can. Something like this (completely
> untested; probably doesn't even compile):
Yes, it works, and AFAIK it has always done. A shorter program to test it:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
int
main(void) {
struct stat s1, s2;
chdir("/");
chroot("/tmp");
stat(".", &s1);
stat("..", &s2);
if (s1.st_dev != s2.st_dev || s1.st_ino != s2.st_ino) {
printf("we are in a chroot\n");
}
return 0;
}
> Actually, come to think of it, I wonder if stat'ing "/.." would work...
> If it does, then you don't even need root.
No, it doesn't. "/" is always equal to "/.."; if not, anyone could
escape anytime from a chroot environment.
Juan
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2007-09-29, 7:28 am |
| | |
| Peter Samuelson 2007-09-29, 7:27 pm |
|
[Roger Leigh]
> But, can you detect it if you are already /inside/ the chroot?
> i.e. chroot(2) has been called at some point previously.
Yes. It's a consequence of two well-known properties of the chroot
call: (1) you can call chroot() even if you are already in a chroot, to
chroot yourself further; and (2) chroot() does not imply chdir(): thus,
it changes your root directory but does not put you inside that root,
if you aren't already inside it.
Thus the classic way to escape a chroot (fortunately, it only works as
root - and this is why use of chroot() is privileged):
chdir("/");
chroot("/tmp"); /* note: cwd is now outside our root, so further
relative chdir is not restricted */
chdir("../../../../../../../../../..");
chroot("."); /* this step is optional */
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
|
|
|
|
|