How to Build a Locked-Down Installation of Puppy

How to do things, solutions, recipes, tutorials
Message
Author
Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#31 Post by Indy'spup »

Oh My!! I just realized what the problem is, incorrect save extension; should be 3fs
:roll:

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#32 Post by Indy'spup »

Ok all back to normal :) frugal install loading previously configured save file at boot and initrd edited and corrected as per earlier post.

moving along to the next phase; I noticed the "Data" directory is infact available at boot now so does the renamed save.bak file need to be moved to this location (data directory)?

Ok Disregard that!! I think the Data directory is a pointer to the home directory because without moving save files the whole deal is working as published
YAY!!

just took forever getting there for a noob!! Thanks rcrsn51 for your patience
:D
Last edited by Indy'spup on Sun 22 May 2011, 23:56, edited 2 times in total.

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#33 Post by rcrsn51 »

Indy'spup wrote:moving along to the next phase; I noticed the "Data" directory is infact available at boot now so does the renamed save.bak file need to be moved to this location (data directory)?
????

It sounds like you made a "Data" directory either in /mnt/sda1 or in /mnt/home. This is incorrect. The mount point /mnt/data already exists in your Puppy filesystem.

You don't need to change anything else. What is the "next phase" to which you want to move?

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#34 Post by Indy'spup »

Oh man you're too quick!!

Just edited my last post :D

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#35 Post by Indy'spup »

Just so I understand what the heck just happened..

the mount point already exists, ok I understand that.

but the mount point is empty? yet the script copies the *save.bak file to the same empty location and renamed it *save.3fs

during boot up puppy loaded the newly created *save.3fs into memory and the file is found in the home directory. I think there is some hard linking going on??

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#36 Post by Indy'spup »

the next phase was where do I place the *save.bak file but I have since accidentally found that out for myself lol

Thanks again rcrsn51 for being so patient with the dumb questions

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#37 Post by Indy'spup »

Ok how about this one.

in the /mnt/home/puppy520 directory i have two files (but others also) namely a *save.bak & *save.3fs

Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless? What about a "What if" statement to compare if a change has been made then skip overwrite if they're the same?

Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??

Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??

Q4 Are the 2fs or 3fs save file extensions reflective of the file system used within the save file??

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#38 Post by rcrsn51 »

Indy'spup wrote:Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless?
Yes. The lines of code you added to the initrd don't check to see if the save file changed in the previous session. But it only takes a few seconds to overwrite the file.
Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
That sounds too complicated. When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.
Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
Each Puppy version is coded to look for a savefile with a particular name. In your case it's either macpup_save.2fs or .3fs. If it finds other files that it thinks might also be savefiles, it gives you a menu.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#39 Post by Indy'spup »

rcrsn51 wrote:
Indy'spup wrote:Q1 at every reboot puppy will overwrite the *save.3fs with the contents of *save.bak But what if the contents did not change? is the file overwritten regardless?
Yes. The lines of code you added to the initrd don't check to see if the save file changed in the previous session. But it only takes a few seconds to overwrite the file.
I guess that depends on the size of the save file and how slow the equipment.. for me this took a minute approximately - a small price to pay but am thinking a changed save file is more rare than it is a daily occurrence is all..
Q2 if I need to make a change to the system AFAIK I need to delete the *save.bak file - make the changes and reboot saving to the *save.3fs file - On reboot to the live cd I only need to rename the *save.3fs file to *save.bak then reboot without saving changes (with respect to the live cd) correct??
That sounds too complicated. When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.
I agree, less steps are better :)
Q3 Is puppy aware of save file name changes? eg is puppy expecting a specific save file as previously saved or if perhaps the name was changed via a live cd, will puppy load the *save file so long as it has a *.3fs or *.2fs file extension??
Each Puppy version is coded to look for a savefile with a particular name. In your case it's either macpup_save.2fs or .3fs. If it finds other files that it thinks might also be savefiles, it gives you a menu.
Interesting, thanks..

sorry i kept returning to add more to each question, but what of Q4 ??

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#40 Post by rcrsn51 »

Q4 Are the 2fs or 3fs save file extensions reflective of the file system used within the save file??
Yes.

User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#41 Post by richard.a »

The Linpus Linux distro as used in the eeepc and which can also be downloaded (ver 9.4) for evaluation does something very similar to rcrsn51 post at the top.

It is certainly foolproof.

Good article guys.

Richard in Adelaide
where it is wet, windy and cold (by Ozzie standards)
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#42 Post by Indy'spup »

rcrsn51 wrote:Most (all?) applications will save by default to /root, so any user data would be lost on a reboot. But there are ways around this.

In Firefox, you can move the hidden profile from /root/.mozilla to /mnt/home outside of the pup_save and replace it with a symlink.

You could do the same thing with any configuration folders like .gxine where the playlist is stored.

Similarly, the folder /root/my-documents could be symlinked to an external location. Users would just need to remember to save to that folder instead of directly into /root.

Ok the procedure is working great thanks again rcrsn51 I'm really happy with the mijnpup frugal install and the modified protected savefile. However it wasn't without a few incidents along the way, like manipulating the save file whilst booted into the same frugal install, like making backups of them and renaming for archiving etc etc. Most of the time I got it right but there were some occasions when my timing was off or I chose to reuse a savefile which had not been shutdown when the backup was made, causing an error at at next boot. yes I know I should have booted into a live cd to make the changes.. But I got to learn somehow right!!

I do have another question!!

If we move any user directories to another partition and symlink them back into the install, don't we need to set puppy to mount that partition for the directories to show up as expected?

If so, how about adding the mount command to the initrd script? without an unmount command?

or is that not the best way to accomplish the task?

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#43 Post by nooby »

When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.

I wrote something I thought would work rather similar as a suggestion to somebody wanting some help but I got a very concerned contributer telling me it was a very bad behavior to suggest something like that.

Maybe what you recommend works due to the fact you use a Live CD.

Would it be dangerous to do the same in a frugal install where you "mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot."

would that be due to puppy being in different pup modes in a Cd live and a Frugal live? I am not savvy enough to get if my suggestion really is exact like the one you suggest here but I thought it was when I wrote it and the person I learned it from had used it between 30 or 40 times without anything bad to happen to the save file. Him being in frugal install while doing it.
I use Google Search on Puppy Forum
not an ideal solution though

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#44 Post by Indy'spup »

The other issue is protecting the boot and pupy files because it appears that the chattr +i command can be reversed by anyone using the chattr -i command.. maybe this is dependent on which root user is using the chattr +i command? Just thinking out loud..

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#45 Post by nooby »

When does one use this chattr +i command? Under what circumstances?
I use Google Search on Puppy Forum
not an ideal solution though

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#46 Post by Indy'spup »

the chattr +i command is used to protect the files on HDD ie the frugal install. chattr -i would unprotect them.


Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system.. Works great for protecting the save file though.

I guess i attribute is perhaps not best for this purpose?
Last edited by Indy'spup on Thu 26 May 2011, 05:19, edited 1 time in total.

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#47 Post by nooby »

Ah that explain why it was impossible to change the Background image on a puppy OS.

the chattr +i command is used to protect the files on HDD ie the frugal install. chattr -i would unprotect them.

The layered thing in RAM appeared to change the background image but it never transferred to the HDD it only showed up as changed in RAM.

Cool one should be able to use that to dumb scripts and lure them to think they have installed malware and in reality them are only in a layer in RAM and get flushed at next boot
I use Google Search on Puppy Forum
not an ideal solution though

User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#48 Post by richard.a »

Indy'spup wrote:Ok the procedure is working great thanks again rcrsn51 I'm really happy with the mijnpup frugal install and the modified protected savefile. However it wasn't without a few incidents along the way, like manipulating the save file whilst booted into the same frugal install, like making backups of them and renaming for archiving etc etc.
Actually frugal install is almost identical in operation to a Live-CD (apart from the CD's booting scripts versus the USB or what-have-you startups... so you can use similar thinking and apply it to both modes. The USB stick (or card, quite often, these days) contains both the .sfs and the .3fs files you need on a live CD boot, as well as the initrd (initial ramdisk) and vmlinuz (kernel).
Indy'spup wrote:Most of the time I got it right but there were some occasions when my timing was off or I chose to reuse a savefile which had not been shutdown when the backup was made, causing an error at at next boot. yes I know I should have booted into a live cd to make the changes.. But I got to learn somehow right!!
There is absolutely nothing to stop you from copying the save file with a slightly different name at any time should you wish. issuing the copy command won't work during an actual save.

Indy'spup wrote:If we move any user directories to another partition and symlink them back into the install, don't we need to set puppy to mount that partition for the directories to show up as expected?

If so, how about adding the mount command to the initrd script? without an unmount command? or is that not the best way to accomplish the task?
The answer IS "yes", you need to mount the partitions... preferably automatically, at boot. I run the MS Windows add-on suite called PortableApps (through WINE)at startup, with its directory structure copied to a "Data" partition I have on every computer, with a symlink to the desktop for manually running its startportableapps.exe file; and I really should put a link into the startup directory with a line like "mount /dev/sda5" (or whatever). Not sure if it would work but it's worth a try.
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#49 Post by rcrsn51 »

Indy'spup wrote:Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system..
Confirmed. Something has changed with the layered filesystem that prevents you from chattr-ing the main sfs file.

It also left a strange symlink in my frugal install. So I have deleted that option from the How-To.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#50 Post by Indy'spup »

rcrsn51 wrote:
Indy'spup wrote:Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system..
Confirmed. Something has changed with the layered filesystem that prevents you from chattr-ing the main sfs file.

It also left a strange symlink in my frugal install. So I have deleted that option from the How-To.
Oh man!! On the other hand this means I'm really not crazy :D

the i attribute doesn't mean the file can not be copied, only that it can't be deleted or renamed or a link made to it (maybe this is the key?) Strange thing is the attribute does not remain with a copied file, you can give a file this attribute then copy it and subsequently delete it!! interesting. Maybe here is a temporary work around for the issue.

I also need to experiment with the s attribute since possibly the attribute will not allow deletion (it zero's out the file then copies it bake afaik but will check on it asap..)

The whole plan is to prevent an accidental and hopefully malicious user from deleting any important file needed. Any determined and skilled hacker will have no trouble in messing with the Frugal install and even a live cd. I mean in five minutes a newbie like me found a huge security issue! If you can call it that since every puppy user has root privileges??

A user (who is allowed root access) can set the +i attribute and a frugal install will not boot again! not at least without some difficulty anyhow. Even a live cd will not boot without the pfix=nocoopy addition to the boot sequence. How many folks know this to be able to fix their install? I was looking at hot plugging the HDD to another machine to get around the security issue, then I found the live cd boot options.

Meanwhile there is a temporary solution, create a .bak file from the puppy.sfs file and secure it with the +i attribute. Then add to the script the command to copy and rename this file to a .sfs extension at the same time as as the save file is copied.

As a temporary fix I added this line to the script

Code: Select all

mount /dev/sda1 /mnt/data
cp /mnt/data/mijnpup520/pup_save.bak /mnt/data/mijnpup520/pup_save.2fs
cp /mnt/data/mijnpup520/lupu_520.bak /mnt/data/mijnpup520/lupu_520.2fs
umount /mnt/data
However I'm thinking about renaming the original files to something less obvious and hiding them somewhat.. Also a script to check if the sfs and save file are ok and decide to skip overwrite as the boot takes a couple of minutes now..


:)

Post Reply