Re: How to detect if inside a buildd chroot
On 9/29/07, Anthony DeRobertis [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Anthony DeRobertis [EMAIL PROTECTED] writes: 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): I agree that this method would work. But, can you detect it if you are already /inside/ the chroot? i.e. chroot(2) has been called at some point previously. -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpV5yV2JLtcu.pgp Description: PGP signature
Re: How to detect if inside a buildd chroot
[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/ signature.asc Description: Digital signature
Re: How to detect if inside a buildd chroot
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
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öge ha scritto: Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer: 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. 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. :/
Re: How to detect if inside a buildd chroot
A Mennucc [EMAIL PROTECTED] writes: 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' 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. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgptLwotFfjzL.pgp Description: PGP signature
Re: How to detect if inside a buildd chroot
On Wed, Sep 26, 2007 at 09:31:36PM +0100, Roger Leigh wrote: A Mennucc [EMAIL PROTECTED] writes: 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' 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Mike Hommey [EMAIL PROTECTED] wrote: 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... 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Sep 25, Sebastian Dröge [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: How to detect if inside a buildd chroot
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:55 +0200 schrieb Simon Richter: 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)? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer: 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 11:35 +0200 schrieb Marco d'Itri: On Sep 25, Sebastian Dröge [EMAIL PROTECTED] 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Hi, Sebastian Dröge wrote: 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)? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Am Dienstag, den 25.09.2007, 12:23 +0200 schrieb Simon Richter: Hi, Sebastian Dröge wrote: 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)? 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti: 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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
tag 439389 help stop Sebastian Dröge [EMAIL PROTECTED] writes: 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Tue, 2007-09-25 at 13:14 +0300, Lars Wirzenius wrote: ti, 2007-09-25 kello 11:55 +0200, Simon Richter kirjoitti: 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 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 [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: How to detect if inside a buildd chroot
Sebastian Dröge [EMAIL PROTECTED] writes: 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? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Tue September 25 2007 5:03:32 am Sebastian Dröge 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 things in chroots -- the problem of installing things that mess with daemons. I've had MTAs restarted, cron restarted, etc. 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? -- John
Re: How to detect if inside a buildd chroot
John Goerzen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
On Tue, 25 Sep 2007 08:18:39 -0500, John Goerzen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
* 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
