From: Antoine M. <an...@na...> - 2005-12-18 19:04:14
|
Paolo, pcap builds and runs fine on amd64 but there is a problem when building with SUBARCH=i386: it uses the wrong version of libpcap.a: ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o arch/um/drivers/pcap_user.o -m elf_i386 -r /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a Whereas the one it needs to link against is here: /emul/linux/x86/usr/lib/libpcap.a Fixing the Makefile is beyond me (probably not that hard), sorry - so I link it manually. After that it works perfectly. On the subject of pcap transport, I couldn't dig the email where you suggested a way of figuring out which libraries should be placed in the chroot, I tried to use the same libraries as I used on a 32-bit setup but it fails to bring up the interface (when it works outside chroot). I tried to guess and even added a few more, here is the chroot's /lib (I made /lib64 a link to /lib in chroot): ld-2.3.5.so libcrack.so.2.8.0 libm.so.6 libnss_compat-2.3.5.so libnss_hesiod-2.3.5.so libpam.so libpamc.so libpcap.so.0.9 librt.so.1 security ld-linux-x86-64.so.2 libcrypt-2.3.5.so libncurses.so libnss_compat.so.2 libnss_hesiod.so.2 libpam.so.0 libpamc.so.0 libpthread-0.10.so libselinux.so.1 tls libc-2.3.5.so libcrypt.so.1 libncurses.so.5 libnss_dns-2.3.5.so libnss_nis-2.3.5.so libpam.so.0.78 libpamc.so.0.78 libpthread.so.0 libsemanage.so.1 libc.so.6 libdl-2.3.5.so libncurses.so.5.4 libnss_dns.so.2 libnss_nis.so.2 libpam_misc.so libpcap.a libresolv-2.3.5.so libsepol.so.1 libcrack.so libdl.so.2 libnsl-2.3.5.so libnss_files-2.3.5.so libnss_nisplus-2.3.5.so libpam_misc.so.0 libpcap.so libresolv.so.2 libutil-2.3.5.so libcrack.so.2 libm-2.3.5.so libnsl.so.1 libnss_files.so.2 libnss_nisplus.so.2 libpam_misc.so.0.78 libpcap.so.0 librt-2.3.5.so libutil.so.1 lib/tls: libc-2.3.5.so libc.so.6 (also lib/security so I can get into the chroot) But that's not enough... and ldd didn't show me anything missing. Any ideas? Thanks Antoine |
From: Blaisorblade <bla...@ya...> - 2005-12-19 16:16:33
|
On Sunday 18 December 2005 20:03, Antoine Martin wrote: > Paolo, > pcap builds and runs fine on amd64 but there is a problem when building > with SUBARCH=i386: it uses the wrong version of libpcap.a: > ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o > arch/um/drivers/pcap_user.o -m elf_i386 > -r /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a > Whereas the one it needs to link against is here: > /emul/linux/x86/usr/lib/libpcap.a This is IMHO a Gentoo bug - it is not setup for compilation of 32-bit binaries using anything else than glibc. I hit this problem with libncurses, when doing make menuconfig ARCH=um (now this was solved as helper programs are built as native again). However, I built uml with libpcap by default for some time - possibly it was before me switching to 64-bit linux. > Fixing the Makefile is beyond me (probably not that hard), it is a bit hard - in this case it probably suffices to add -L searchpath (i.e. -L /emul/linux/x86/usr/lib/ ), but it's non-standard (aka only Gentoo works this way) - and merging fixes for every possible distro is not a good idea. > sorry - so I > link it manually. After that it works perfectly. > On the subject of pcap transport, I couldn't dig the email where you > suggested a way of figuring out which libraries should be placed in the > chroot, I tried to use the same libraries as I used on a 32-bit setup > but it fails to bring up the interface (when it works outside chroot). Don't know what I did suggest, but using strace -e open() (or, even better, ltrace -e dlopen ) would probably find the point where it's failing and the failed cmd line. > I tried to guess and even added a few more, here is the chroot's /lib (I > made /lib64 a link to /lib in chroot): > ld-2.3.5.so libcrack.so.2.8.0 libm.so.6 > libnss_compat-2.3.5.so libnss_hesiod-2.3.5.so libpam.so Good thing, libnss_* is probably good - but don't forget /etc/nsswitch.conf and /etc/pam.d/* - /etc/pam.conf > (also lib/security so I can get into the chroot) That's for su, right? There are some tools (including "compartment") to combine chroot + su together. > But that's not enough... and ldd didn't show me anything missing. Ldd won't help you with dynamically loaded libraries. Likely, a recursive "strings object|grep lib" will help - recursive means "do that also on libraries found this way". Also, I see you're using SeLinux. I don't know anything about its library handling, and possibly it's going to make the story more difficult. However, strace/ltrace as suggested above should diagnose any problem. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Blaisorblade <bla...@ya...> - 2005-12-19 18:39:53
|
On Monday 19 December 2005 17:16, Blaisorblade wrote: > On Sunday 18 December 2005 20:03, Antoine Martin wrote: > > Paolo, > > > > pcap builds and runs fine on amd64 but there is a problem when building > > with SUBARCH=i386: it uses the wrong version of libpcap.a: > > ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o > > arch/um/drivers/pcap_user.o -m elf_i386 > > -r /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a > > > > Whereas the one it needs to link against is here: > > /emul/linux/x86/usr/lib/libpcap.a > > This is IMHO a Gentoo bug - it is not setup for compilation of 32-bit > binaries using anything else than glibc. I hit this problem with > libncurses, when doing make menuconfig ARCH=um (now this was solved as > helper programs are built as native again). > However, I built uml with libpcap by default for some time - possibly it > was before me switching to 64-bit linux. No, the thing works but only because I indeed symlinked 32-bit libraries inside /usr/lib32. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com |
From: Antoine M. <an...@na...> - 2005-12-19 18:34:00
Attachments:
uml-pcap-subarchi386-linkerfix.patch
|
> > pcap builds and runs fine on amd64 but there is a problem when building > > with SUBARCH=i386: it uses the wrong version of libpcap.a: > > ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o > > arch/um/drivers/pcap_user.o -m elf_i386 > > -r /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a > > > Whereas the one it needs to link against is here: > > /emul/linux/x86/usr/lib/libpcap.a > > This is IMHO a Gentoo bug - I'll ask the gentoo devs, for the time being I can copy this library manually to /usr/lib32 (which is the standard location for 32-bit libs on amd64) But the problem remains, the linker should use: -r /usr/lib32/libpcap.a and not ../../../libpcap.a which ends up as /usr/lib (which points to /usr/lib64 on standard distros) But only when building with SUBARCH=i386. So I added this statement to the Makefile (patch attached) and now all is well: +ifeq ($(SUBARCH),i386) +LDFLAGS_pcap.o := -r /usr/lib32/libpcap.a +else > Good thing, libnss_* is probably good - but don't forget /etc/nsswitch.conf > and /etc/pam.d/* - /etc/pam.conf Yep, they're all there... see: http://uml.nagafix.co.uk/SELinux/chroot/ This chroot example is here for SELinux but it applies just as well to others. I think I'll rebuild it with compartment and build su without pam to trim it down even more. > > (also lib/security so I can get into the chroot) > That's for su, right? There are some tools (including "compartment") to > combine chroot + su together. Yep, it's a shame compartment does not ship with all distros. chroot without su is pointless (since you can use 'chroot-again' to escape) changing uid/guid should really be included in chroot. > Also, I see you're using SeLinux. I don't know anything about its library > handling, and possibly it's going to make the story more difficult. It can do that... but the good thing is that it can be disabled. > However, > strace/ltrace as suggested above should diagnose any problem. Cool - I'll try that and report back. Many thanks Antoine |
From: Blaisorblade <bla...@ya...> - 2005-12-19 19:27:20
|
On Monday 19 December 2005 19:33, Antoine Martin wrote: > > > pcap builds and runs fine on amd64 but there is a problem when building > > > with SUBARCH=i386: it uses the wrong version of libpcap.a: > > > ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o > > > arch/um/drivers/pcap_user.o -m elf_i386 > > > -r /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a > > > Whereas the one it needs to link against is here: > > > /emul/linux/x86/usr/lib/libpcap.a > > This is IMHO a Gentoo bug - > I'll ask the gentoo devs, for the time being I can copy this library > manually to /usr/lib32 (which is the standard location for 32-bit libs > on amd64) > But the problem remains, the linker should use: > -r /usr/lib32/libpcap.a > and not ../../../libpcap.a which ends up as /usr/lib (which points > to /usr/lib64 on standard distros) > But only when building with SUBARCH=i386. > So I added this statement to the Makefile (patch attached) and now all > is well: > +ifeq ($(SUBARCH),i386) > +LDFLAGS_pcap.o := -r /usr/lib32/libpcap.a > +else Yep, seen that - obviously this patch can't be merged as the thing is non-standard (not that I know, I just guess this). Just a first guess however. Also, by gross testing on my system (guess Gentoo devs have screwed up something else on your system, too). Note the -m32 difference and lib32 vs. lib64: $ gcc -print-file-name=libpcap.a /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpcap.a $ gcc -m32 -print-file-name=libpcap.a /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib32/libpcap.a > chroot without su is pointless (since you can use 'chroot-again' to > escape) Indeed. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Antoine M. <an...@na...> - 2005-12-19 21:47:14
|
> > So I added this statement to the Makefile (patch attached) and now all > > is well: > > +ifeq ($(SUBARCH),i386) > > +LDFLAGS_pcap.o := -r /usr/lib32/libpcap.a > > +else ahh, so this is the right way to find the lib... (cool) > $ gcc -print-file-name=libpcap.a > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpcap.a > $ gcc -m32 -print-file-name=libpcap.a > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib32/libpcap.a Works for me (tm) too. Can this be merged? (I can't see any reason not to now) --- linux-2.6.15-rc6-x86-broken/arch/um/drivers/Makefile 2005-12-19 18:07:17.000000000 +0000 +++ linux-2.6.15-rc6-x86/arch/um/drivers/Makefile 2005-12-19 21:45:17.000000000 +0000 @@ -17,7 +17,11 @@ port-objs := port_kern.o port_user.o harddog-objs := harddog_kern.o harddog_user.o +ifeq ($(SUBARCH),i386) +LDFLAGS_pcap.o := -r $(shell $(CC) $(CFLAGS) -m32 -print-file-name=libpcap.a) +else LDFLAGS_pcap.o := -r $(shell $(CC) $(CFLAGS) -print-file-name=libpcap.a) +endif targets := pcap_kern.o pcap_user.o |
From: Blaisorblade <bla...@ya...> - 2005-12-20 14:24:10
|
On Monday 19 December 2005 22:47, Antoine Martin wrote: > > > So I added this statement to the Makefile (patch attached) and now all > > > is well: > > > +ifeq ($(SUBARCH),i386) > > > +LDFLAGS_pcap.o := -r /usr/lib32/libpcap.a > > > +else > > ahh, so this is the right way to find the lib... (cool) Suggested by Al Viro IIRC... > > $ gcc -print-file-name=libpcap.a > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpcap.a > > $ gcc -m32 -print-file-name=libpcap.a > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib32/libpcap.a > > Works for me (tm) too. > Can this be merged? (I can't see any reason not to now) Wait a moment - CFLAGS is supposed to contain -m32: arch/um/Makefile-i386: CFLAGS += $(call cc-option,-m32) so there is something strange going on - but have you tested without this patch _after_ symlinking libraries into /usr/lib32? -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Antoine M. <an...@na...> - 2005-12-20 16:25:51
|
> > > $ gcc -print-file-name=libpcap.a > > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpcap.a > > > $ gcc -m32 -print-file-name=libpcap.a > > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib32/libpcap.a > > > > Works for me (tm) too. > > > Can this be merged? (I can't see any reason not to now) > > Wait a moment - CFLAGS is supposed to contain -m32: > > arch/um/Makefile-i386: > > CFLAGS += $(call cc-option,-m32) > > so there is something strange going on - but have you tested without this > patch _after_ symlinking libraries into /usr/lib32? Yes, that works and in fact the patch solved nothing: I forgot to remove the library from /usr/lib32 and that's what it used - DOH. # gcc -m32 -print-file-name=libpcap.a /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a I thought the '-m32' would force it to try to find the 32 bit version? So in the end the only way to get it to build is to copy the library to /usr/lib32... no patch needed. Antoine |
From: Blaisorblade <bla...@ya...> - 2005-12-20 19:25:10
|
On Tuesday 20 December 2005 17:25, Antoine Martin wrote: > > > > $ gcc -print-file-name=libpcap.a > > > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpcap.a > > > > $ gcc -m32 -print-file-name=libpcap.a > > > > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib32/libpcap.a > > > > > > Works for me (tm) too. > > > > > > Can this be merged? (I can't see any reason not to now) > > > > Wait a moment - CFLAGS is supposed to contain -m32: > > > > arch/um/Makefile-i386: > > > > CFLAGS += $(call cc-option,-m32) > > > > so there is something strange going on - but have you tested without this > > patch _after_ symlinking libraries into /usr/lib32? > > Yes, that works and in fact the patch solved nothing: I forgot to remove > the library from /usr/lib32 and that's what it used - DOH. > # gcc -m32 -print-file-name=libpcap.a > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../libpcap.a > I thought the '-m32' would force it to try to find the 32 bit version? -m32 means "compile a 32bit program". Gcc is smart enough to correct the libraries search path. Gentoo is not smart enough to put emulation libraries in /usr/lib32. Btw, which emul- package did you install to get libpcap? Also there's almost no .a file in /emul - they're intended to be used for .so (dynamic) libraries only, I guess - you sneaked it there, right? However, the Gentoo bug is still there, and you followed its example in putting your libpcap.a. I'm discussing the issue at: http://bugs.gentoo.org/show_bug.cgi?id=100923 -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Rob L. <ro...@la...> - 2005-12-20 20:01:22
|
On Monday 19 December 2005 12:33, Antoine Martin wrote: > I think I'll rebuild it with compartment and build su without pam to > trim it down even more. > > > > (also lib/security so I can get into the chroot) > > > > That's for su, right? There are some tools (including "compartment") to > > combine chroot + su together. > > Yep, it's a shame compartment does not ship with all distros. > chroot without su is pointless (since you can use 'chroot-again' to > escape) changing uid/guid should really be included in chroot. This is the first I've heard of it, and after few minutes of googling the best I can find on it is this: http://www.suse.de/~marc/SuSE.html Which is from February 2001. Is that the newest version? Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. |
From: Antoine M. <an...@na...> - 2005-12-20 20:25:06
|
On Tue, 2005-12-20 at 14:01 -0600, Rob Landley wrote: > On Monday 19 December 2005 12:33, Antoine Martin wrote: > > Yep, it's a shame compartment does not ship with all distros. > > chroot without su is pointless (since you can use 'chroot-again' to > > escape) changing uid/guid should really be included in chroot. > > This is the first I've heard of it, and after few minutes of googling the best > I can find on it is this: > http://www.suse.de/~marc/SuSE.html > > Which is from February 2001. > > Is that the newest version? Probably, all it does is: chroot / change uid/gid: chroot(chroot_path) setgid(set_group) setuid(set_user) Looking at it, there is very little code in there - which is a good thing! Less likely to go wrong. Antoine |
From: Blaisorblade <bla...@ya...> - 2005-12-20 20:44:18
Attachments:
chroot-setuid.c
|
On Tuesday 20 December 2005 21:01, Rob Landley wrote: > On Monday 19 December 2005 12:33, Antoine Martin wrote: > > I think I'll rebuild it with compartment and build su without pam to > > trim it down even more. > > > > (also lib/security so I can get into the chroot) > > > That's for su, right? There are some tools (including "compartment") to > > > combine chroot + su together. > > Yep, it's a shame compartment does not ship with all distros. > > chroot without su is pointless (since you can use 'chroot-again' to > > escape) changing uid/guid should really be included in chroot. > This is the first I've heard of it, and after few minutes of googling the > best I can find on it is this: > http://www.suse.de/~marc/SuSE.html > Which is from February 2001. > Is that the newest version? Don't know, guess yes - and that's more or less the URL I had. I know it just because it was mentioned here (by Gerd Knorr, maybe - former SuSE UML maintainer). -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <bla...@ya...> - 2005-12-21 18:13:27
|
Forgot to say one thing - the attachment is a minimal chroot-setuid C program written by Jeff Dike for his book - it's minimal and trivial to verify. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com |
From: Anthony B. <br...@st...> - 2005-12-22 17:57:44
Attachments:
chrootuidgid.c
|
I don't think the attachment made it into the email. However, I am attaching one that we've used with good success. It allows us to also specify a "nice" level for the UML kernel in addition to the chroot-setuid. Tony > -----Original Message----- > From: use...@li... > [mailto:use...@li...]On Behalf Of > Blaisorblade > Sent: Wednesday, December 21, 2005 10:13 AM > To: use...@li... > Cc: Rob Landley; Antoine Martin > Subject: Re: [uml-devel] Re: pcap cross-linking [PATCH] > > > Forgot to say one thing - the attachment is a minimal > chroot-setuid C program > written by Jeff Dike for his book - it's minimal and trivial to verify. > > -- > Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". > Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ > 215621894) > http://www.user-mode-linux.org/~blaisorblade > > > ___________________________________ > Yahoo! Messenger: chiamate gratuite in tutto il mondo > http://it.messenger.yahoo.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > |
From: Blaisorblade <bla...@ya...> - 2005-12-23 16:11:48
|
On Thursday 22 December 2005 18:57, Anthony Brock wrote: > I don't think the attachment made it into the email. It was in the previous one but I had forgot to describe it - sorry for the misunderstanding. > However, I am > attaching one that we've used with good success. It allows us to also > specify a "nice" level for the UML kernel in addition to the chroot-setuid. Nice tool, well written. Only one minor complaint: you do the following sequence (excluding error paths): chdir(chroot_dir); chroot(chroot_dir); this will fail needlessly if a relative path is used. Replacing the chroot with chroot(".") would be better, IMHO. One question: would chroot(chroot_dir); chdir("/"); work equally well? I've not seen it used so I wonder (a bit) if there can be some hidden bug. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Anthony B. <br...@st...> - 2005-12-26 07:48:05
Attachments:
chrootuidgid.c
|
> On Friday December 23, 2005 at 8:11 AM, Blaisorblade wrote: > Only one minor complaint: you do the following sequence (excluding error > paths): > > chdir(chroot_dir); > chroot(chroot_dir); > > this will fail needlessly if a relative path is used. Thanks! This hasn't been an issue since we always use full paths in our environment. However, it's definitely a bug. I'm attaching a version with your suggested change. > Replacing the chroot with chroot(".") would be better, IMHO. > > One question: would > chroot(chroot_dir); > chdir("/"); > work equally well? > I've not seen it used so I wonder (a bit) if there can be some hidden bug. I'm more comfortable creating a chroot where the "jailed" process never has an external file reference. However, I don't see why this wouldn't work. Logically, it should be identical. Tony |
From: Rob L. <ro...@la...> - 2005-12-31 16:56:20
|
On Friday 23 December 2005 10:11, Blaisorblade wrote: > One question: would > chroot(chroot_dir); > chdir("/"); > work equally well? > I've not seen it used so I wonder (a bit) if there can be some hidden bug. http://www.ussg.iu.edu/hypermail/linux/kernel/0511.2/0185.html Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. |
From: Blaisorblade <bla...@ya...> - 2006-01-01 18:52:18
|
On Thursday 29 December 2005 21:12, Rob Landley wrote: > On Friday 23 December 2005 10:11, Blaisorblade wrote: > > One question: would > > chroot(chroot_dir); > > chdir("/"); > > work equally well? > > I've not seen it used so I wonder (a bit) if there can be some hidden > > bug. > > http://www.ussg.iu.edu/hypermail/linux/kernel/0511.2/0185.html So? I've read this message, but my (original) main question was: is > > chroot(chroot_dir); > > chdir("/"); the same as > > chdir(chroot_dir); > > chroot("."); ? Maybe there was a misunderstanding, but the answer to the question is still "it seems yes, until somebody shows me I'm wrong". I know that yes, chroot() has all the other problems (like the "root can escape" described in man 2 chroot, or the one by Linus). -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com |
From: Rob L. <ro...@la...> - 2006-01-01 21:01:22
|
On Sunday 01 January 2006 12:51, Blaisorblade wrote: > So? I've read this message, but my (original) main question was: > is > > > > chroot(chroot_dir); > > > chdir("/"); > > the same as > > > > chdir(chroot_dir); > > > chroot("."); > > ? All chroot does is change the / value. It doesn't recalculate .. for the current directory, so if you don't chdir after the chroot you may wind up with .. pointing someplace it shouldn't. Rob -- Steve Ballmer: Innovation! Inigo Montoya: You keep using that word. I do not think it means what you think it means. |
From: Blaisorblade <bla...@ya...> - 2006-01-02 20:11:38
|
On Sunday 01 January 2006 22:01, Rob Landley wrote: > On Sunday 01 January 2006 12:51, Blaisorblade wrote: > > So? I've read this message, but my (original) main question was: > > is > > > > > > chroot(chroot_dir); > > > > chdir("/"); > > > > the same as > > > > > > chdir(chroot_dir); > > > > chroot("."); > > > > ? > > All chroot does is change the / value. It doesn't recalculate .. for the > current directory, so if you don't chdir after the chroot you may wind up > with .. pointing someplace it shouldn't. I know that, but in fact I included chdir("/") after the chroot. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |