Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 23 Oct 2014, 03:04
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
HowTo use chroot for setting current shell`s "/" ?
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 3 [33 Posts]   Goto page: 1, 2, 3 Next
Author Message
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Sun 17 Jun 2012, 22:49    Post subject:  HowTo use chroot for setting current shell`s "/" ?  

I was thinking chroot may solve path problems for running apps. in odd places.
If it will change the root to an apps. dir. in the current running shell,
then all it`s deps. will be found, libs. and all the other files placed in the dir.

As I understand it, the specified dir. will become / for paths starting with / .
I`m not sure what will be different about relative paths, probably nothing.

### Of course if apps. were written with relative paths, then no problem.

From the Man. page for chroot:
Quote:
chroot changes the root directory to that specified in path.
This directory will be used for path names beginning with /.
The root directory is inherited by all children of the current process.


Error running chroot in an app. dir.:
Code:
sh# chroot /mnt/sdb3/apps_Puppy/breakout2/LBreakout2
chroot: cannot run command `/bin/bash': No such file or directory

### And while trying to run the app.:
sh# chroot /mnt/sdb3/apps_Puppy/breakout2/LBreakout2 bin/lbreakout2
chroot: cannot change root directory to bin/lbreakout2: Not a directory
sh#


The current path is: /mnt/sdb3/apps_Puppy/breakout2/LBreakout2
And in it is the /dir./file: bin/lbreakout2


### And this:

Code:
cd /new-root
pivot_root . old-root
exec chroot . sh <dev/console >dev/console 2>&1


But when run:
Code:
sh-4.1# pivot_root . old-root
pivot_root: No such file or directory

sh-4.1# pivot_root . ../0
pivot_root: Invalid argument

sh-4.1# pivot_root --help   
BusyBox v1.16.2 (2010-06-19 18:02:46 GMT-8) multi-call binary.

Usage: pivot_root NEW_ROOT PUT_OLD

Move the current root file system to PUT_OLD and make NEW_ROOT
the new root file system


### I don`t get what the last Help line means:
............. Move the current root file system to PUT_OLD

### It`s rather unclear exactly what each of the 2 commands is doing.
.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Mon 18 Jun 2012, 03:32    Post subject:  

1) then you need a bash binary with its ldd depends in your app dir too, probably all the /bin and /sbin at least if not also /usr/bin .

Its easier to chroot to a complete full installation then into a separate folder on the partition ie chroot /mnt/sdb2 .

2) pivot_root you can see in action in /sbin/init script of Puppy 5 series :

You need to create a folder old_root at least .
Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 18 Jun 2012, 07:26    Post subject:  

Hey Karl; I kinda figured the app. dir. might need to be complete.

This is the error with the link: /tmp/0/bin/bash => ../../../bin/bash
Code:
sh-4.1# chroot /tmp/0
chroot: cannot run command `/bin/bash': Too many levels of symbolic links

So I copied the real bash file to /tmp/0/bin and got this error:
Code:
sh-4.1# chroot /tmp/0
chroot: cannot run command `/bin/bash': No such file or directory

The first one saw the link, but it`s like the second one didn`t see bash.

It seems that you`re right... RATS!!!
If you can see a way to get it to work, it might be a real god send.
But it looks like I`m barking up the wrong tree ( Puppy joke Laughing ).

I`m hoping to find a silver bullet that will make misplaced apps. work.
I really don`t like the mixed bag of tricks I`ve used to make AppDirs.
Want something that`s reliable and allows placing the app. anywhere.
The junction would do it, but it has to work for all deps. in all apps.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Mon 18 Jun 2012, 08:03    Post subject:  

The following example works. You need static busybox (get it from puppy's initrd). For chroot example, the busybox needs "sh" applet (try "busybox sh" to see if exist). For pivot_root example, you need busybox with "pivot_root" applet (otherwise you cannot return to your original root and have to reboot - you've been warned). Of course preferably the busybox has "ls", "cat", and other applets for investigation and poking around.

chroot example
Code:
mount -t tmpfs tmpfs /mnt/data
cp /your/static/busybox /mnt/data
chroot /mnt/data ./busybox sh
...
# do anything you want, remember you only have busybox there
# chroot only affect the current shell process
./busybox ls
...
exit  # when done
umount /mnt/data


pivot_root example
Code:
mount -t tmpfs tmpfs /mnt/data
cp /your/static/busybox /mnt/data
cd /mnt/data
mkdir old_root
./busybox pivot_root . old_root
...
# do anything you want, remember you only have busybox there
# pivot_root affects entire system, you see that you won't be able to start anything from the desktop anymore
./busybox ls
./busybox ls old_root
./busybox cat old_root/proc/mounts
...
# when done
./busybox pivot_root old_root old_root/mnt/data
umount /mnt/data

Note: there is also "switch_root", which is used by all current puppies. Warning: DO NOT USE IT, or you will be at the happy end of having your entire / wiped out ...

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 18 Jun 2012, 08:50    Post subject:  

Wow jamesbond, you really are a sleuth and a sneaky guy!

The idea is for a script to do this and run an app. in the new root.
So everything gets dumped when the script`s app. and shell exit.
It seems like that would solve the "not being able to return" problem.

You used tmpfs, is that the only way it`s gonna work?
I`d like to make the app`s. dir. the new root while the app`s. running.

pivot_root has the old root inside it, right?
So it would be possible to get at the rest of the system?
Obviously the O.S. still has to work normally for the app. in the jail.
This seems to be the real problem to overcome, or be defeated by.


This makes the idea of a "junction" or "multi. target link" seem easy.
I was telling Karl that the kernel reads link info. and parses paths.
The current normal link can hold a path, but the kernel can`t use it.
All that`s needed is a little code to thread the 2 processes together.
Making a new link over the old one changes the multi. link`s paths.
So a multi. link in place of /lib or /etc could point to many app. dirs.
As with $PATH, the path order sets hierarchy like a union`s layers.
Much simpler than a union, no cpu load, and none of it`s problems.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Mon 18 Jun 2012, 09:07    Post subject: Static busybox  

Hers a static 1.18.3 upx in case Lupu still uses 1.4 .
Should have all common applets included .

Newer pups may have 1.18, 1.19 or 1.20 i think in intrd.gz

http://murga-linux.com/puppy/viewtopic.php?p=522807&search_id=1379444889#522807

And yes, i think i have wiped once a full installation too as jamesbond described (was Xubuntu-10.04) or was it rm -rf instead of rmdir .. :Oops:
Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 18 Jun 2012, 09:21    Post subject:  

Loosing what`s in the Save file`s bad enough, but a full install.!
If you backup your Save file then recovery is easy.
And don`t you just love those Squash files! A solid foundation...

I really try to stay away from rm -r , it`s a recipe for disaster.

I`ll give the upx file a try and see what luck I have experimenting.

Thanks Karl and jamesbond.
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3972
Location: Kiel,Germany

PostPosted: Mon 18 Jun 2012, 10:37    Post subject:  

Quote:
And don`t you just love those Squash files! A solid foundation...

I don't know if i love them, but they are really practical and handy .

What i don't love really don't love is the standard Puppy icon for them .
application-puppy-sfs-red2.png
 Description   
 Filesize   3.03 KB
 Viewed   1603 Time(s)

application-puppy-sfs-red2.png

application-puppy-sfs-red.png
 Description   
 Filesize   2.93 KB
 Viewed   1604 Time(s)

application-puppy-sfs-red.png

Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 18 Jun 2012, 19:42    Post subject:  

I agree, it`s pretty ugly, something being squashed makes sense.

I tried to make one, but I don`t know how to work mtPaint.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Mon 18 Jun 2012, 20:44    Post subject:  

sunburnt wrote:
Wow jamesbond, you really are a sleuth and a sneaky guy!
You can call M and recommend a promotion for me Smile Been tired of living in the fields, too much excitement can get to your nerve Laughing

Quote:
The idea is for a script to do this and run an app. in the new root.
So everything gets dumped when the script`s app. and shell exit.
It seems like that would solve the "not being able to return" problem.
I'm afraid none can be easily used for that purpose. Chroot is a little bit more prospective.

1. With chroot - the app basically lose all access to the real root; that means if the app uses shared library --- *any share library* (including libc, gtk, etc) --- these shared library must be made available inside the chrooted directory. Symlink isn't enough (because the symlink will point to the original root, which, for all intent and purposes, no longer exist when you run chroot), it has to be the real file. Plus the fact that the app cannot access anything outside the new root - e.g. if the app is an music player, it won't be able to access your MP3 files.
There is a way to go around this, you can make whatever directory in the original root available in the chrooted directory using bind mounts.

2. With pivot_root, I think you can forget it. It changes the root *for the entire system* not only for the shell / app you're trying to run.

Quote:
You used tmpfs, is that the only way it`s gonna work?
I`d like to make the app`s. dir. the new root while the app`s. running.
In theory this can be used for any filesystem including squashfs, but see my comment above.

Quote:
pivot_root has the old root inside it, right?
So it would be possible to get at the rest of the system?
yes, but ...
Quote:
Obviously the O.S. still has to work normally for the app. in the jail.This seems to be the real problem to overcome, or be defeated by.
no, the OS won't work normally after you pivot_root, unless the new root contains all the files used and needed by the OS (which, in this case, you'd end up using something like unionfs anyway)

Quote:
This makes the idea of a "junction" or "multi. target link" seem easy.
I was telling Karl that the kernel reads link info. and parses paths.
The current normal link can hold a path, but the kernel can`t use it.
All that`s needed is a little code to thread the 2 processes together.
Making a new link over the old one changes the multi. link`s paths.
So a multi. link in place of /lib or /etc could point to many app. dirs.
As with $PATH, the path order sets hierarchy like a union`s layers.
Much simpler than a union, no cpu load, and none of it`s problems.
I'm not sure I'm getting what you mean Embarassed
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Mon 18 Jun 2012, 21:42    Post subject:  

That`s what I was thinking, all the deps. have to be in the dir. Too much.

Bind mounts are like regular mounts as they cover up what`s preexisting.
So to have /usr/share in the dir. will be a problem mounting on it.
Only paths that don`t exist in the dir. can be brought in, correct?

# I suppose complete stand-alone apps. could work this way?
But it`s hard to see how an app. would show a GUI, or do I/O.


### A multi. target link.

A link: /lib
................... => /usr/lib
................... => /usr/local/lib
................... => /mnt/sdb1/lib

Try this: ln -s /usr/lib:/usr/local/lib:/mnt/sdb1/lib /lib0

Hover over it in ROX Filer and you`ll see the path is there.
But ROX shows it as dead because it`s unusable.

So the kernel just needs a small piece of code to thread it`s
path parsing code with the link recognition code to make it work.
There`s probably other things I haven`t forseen, ROX, etc.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Tue 19 Jun 2012, 03:43    Post subject:  

You don't have to copy all deps into the chroot. Use 'mount --bind' to make the real root files available inside the chroot. bind them under the dir which will be the chroot before chrooting into the dir. You don't need pivot_root usually -that's usually used at the end of an initrd. Of course I mean to use the *real* mount and not some busybox or script front-end thingy...
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Tue 19 Jun 2012, 03:52    Post subject:  

Thanks amigo, I hope this doesn`t qualify as a "script thingy".


# NEW Update: I have / bind mounted on /tmp/0 for testing.

All of the entire file system is available except mount points.
But the partition links are good in /root, so all of it is accessible.

But it has no $PATH, even though I set it and export it in the script: setchroot.
Code:
#!/bin/sh
#########   Bind mount dirs. and chroot, or exit and umount.

if [ `mount |grep /tmp/0` ];then
   exit
   umount /tmp/0
else
   PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/X11R7/bin:/root/my-applications/bin:/root/my-applications/sbin
   export PATH

   mount --bind / /tmp/0

   [ $? -eq 0 ]&& chroot /tmp/0 &&

      [ $? -gt 0 ]&& umount /tmp/0
fi


# This is looking more possible to do... Now how to add the AppDir.
.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Tue 19 Jun 2012, 14:02    Post subject:  

chroot should be invoked like this:
Code:
chroot dir command

Also, you need a copy of chroot under the chroot for full functionality. If you want an interactive chroor you call it like this:
Code:
chroot dir /bin/bash

To leave the chroot, use 'exit'. experiment using the 'pwd' command to verify you are really in the chroot.
By 'script thingy', I was referring to that horrendous thing called 'mount' which is used by Puppy. I still cannot understand why you would use such an abhorrant thing -especially when the 'real' thing is there all along (FULL-mount) -oh, but that isn't the real thing either -just a cut-down busybox version....
Another thing, you have doen the easy thing by binding '/' under your chrott, but if you want to limit the 'exposure' or availability of items, you can always create several bind points:
Code:
mkdir mychroot mychroot/etc mychroot/bin
mount --bind /etc mychroot/etc
mount --bind /bin mychroot/bin


Running multiple commands as an argument to chroot is a bit tricky -cat them together into a single variable argument:
CHROOTCMD="first-command ; second-comand"
chroot dir $CHROOTCMD
Or place the command sto be run under the chroot into a script which you copy into the chroot area before running the chroot command:
Code:
mkdir mychroot mychroot/tmp
cp myscript mychroot/tmp/myscript
chroot mychroot /tmp/myscript


In 'src2pkg' I use a combination of 'mount --bind' along with a temporary unionfs to create a safe way to install software in an out-of-the-way place when creating packages -for cases where there is no DESTDIR support. This avoids the problem of having the chroot have read-write access to the bind-ed content.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Tue 19 Jun 2012, 15:59    Post subject:  

As always, you`re a fountain of info. amigo. Thanks!

The Q that comes to my mind is: How would I/O be done?
And how would X and the desktop work if they are not available?
I`m sure there`s probably many things I haven`t even thought of.

It will be tough going listing everything needed in the chroot.
This is why I figured that most of the dir. tree is needed inside.

The mount covers up anything inside, so the same problems still exist.
If a file is needed in /usr/bin and the app. exec. is there too, problem.
Add to $PATH and $LD_LIBRARY_PATH to fix misplaced exec. and libs.
In /usr/share probably only the apps. dirs. are needed, so no mount.


# So the premount chroot dir.: /usr/APP/bin , /usr/APP/lib , /usr/share .
Mount all in: / . And in /usr mount: /bin, /sbin, /lib, /local, /X11R7 .

# Does this sound like a good plan?
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 3 [33 Posts]   Goto page: 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1188s ][ Queries: 13 (0.0098s) ][ GZIP on ]