MLDonkey in compartment => no name-resolution for BitTorrent
Hi! I'm running MLDonkey with compartment (http://www.suse.de/~marc/SuSE.html) and I'd like to use BitTorrent... The problem is that mlnet can't look up the IP of the Tracker for the torrent-file. e.g. when I try to get Knoppix with KNOPPIX_V3.9-2005-05-27-DE.torrent I get error-messages Error: torrent.unix-ag.uni-kl.de: address not found in the log. mlnet itself is a static binary, so it won't use libs for name-resolution I think. I start mlnet with a start-script which executes: /usr/sbin/compartment --chroot $CHROOT_PATH --user $MLDONKEY_USER --group $MLDONKEY_GROUP --fork "$MLDONKEY" 2>&1 >> $CHROOT_PATH/$MLDONKEY_LOG Anyone an idea what I could do to solve this? -- Eat, sleep and go running, David Hücking. Encrypted eMail welcome! GnuPG/ PGP-Key: 0x57809216. Fingerprint: 3DF2 CBE0 DFAA 4164 02C2 4E2A E005 8DF7 5780 9216
David Huecking wrote: Care to tell why you think this is appropriate in suse-security?
I start mlnet with a start-script which executes: /usr/sbin/compartment
--chroot $CHROOT_PATH I suggest you think about this option (^-^) --user $MLDONKEY_USER --group
$MLDONKEY_GROUP --fork "$MLDONKEY" 2>&1 >> $CHROOT_PATH/$MLDONKEY_LOG
Sandy -- List replies only please! Please address PMs to: news-reply (@) japantest (.) homelinux (.) com
On Samstag 06 August 2005 22:17, Sandy Drobic wrote:
David Huecking wrote:
Care to tell why you think this is appropriate in suse-security? To my mind securing a network-application especially with a tool created by a guy who works/ worked for SuSE should be ok in suse-security.
I start mlnet with a start-script which executes: /usr/sbin/compartment
--chroot $CHROOT_PATH
I suggest you think about this option (^-^)
Ok, I know that the process is in a chroot-jail. But what would I have to put in the chroot-enviroment also? - I started mlnet outside a chroot and did a lsof -P -T -p <mlnet-PID>> and saw that some files from /lib were accessed (even though ldd showed a static binary...). I copied them into the chroot, added /etc/resolv.conf, /etc/hosts, /etc/nsswitch.conf and a tmp-directory. - Didn't work. When I did a lsof -P -T -p <mlnet-PID>> on the chrooted mlnet I didn't see access to files of /lib (not the one in the chroot, nor any other). Hey, please don't make look to stupid and have a suggestion for me! (-: -- Eat, sleep and go running, David Hücking. Encrypted eMail welcome! GnuPG/ PGP-Key: 0x57809216. Fingerprint: 3DF2 CBE0 DFAA 4164 02C2 4E2A E005 8DF7 5780 9216
David Huecking wrote:
On Samstag 06 August 2005 22:17, Sandy Drobic wrote:
David Huecking wrote:
Care to tell why you think this is appropriate in suse-security?
To my mind securing a network-application especially with a tool created by a guy who works/ worked for SuSE should be ok in suse-security.
Cute... though it seems that you don't want to secure a program, you want to get it running. (^-^)
I start mlnet with a start-script which executes: /usr/sbin/compartment
--chroot $CHROOT_PATH
I suggest you think about this option (^-^)
Ok, I know that the process is in a chroot-jail. But what would I have to put in the chroot-enviroment also? - I started mlnet outside a chroot and did a lsof -P -T -p <mlnet-PID>> and saw that some files from /lib were accessed (even though ldd showed a static binary...). I copied them into the chroot, added /etc/resolv.conf, /etc/hosts, /etc/nsswitch.conf and a tmp-directory. - Didn't work. When I did a lsof -P -T -p <mlnet-PID>> on the chrooted mlnet I didn't see access to files of /lib (not the one in the chroot, nor any other). Hey, please don't make look to stupid and have a suggestion for me! (-:
I can not help you with mlnet directly but I suggest you do a "strace mlnet" to see what it might try to access. Sandy -- List replies only please! Please address PMs to: news-reply (@) japantest (.) homelinux (.) com
participants (2)
-
David Huecking -
Sandy Drobic