Puppy Linux Discussion Forum

stemsee · Joined: 27 Jun 2013 Posts: 2572 Location: In The Way

sfs-direct-save is a script which saves changes fo an sfs file S_*_date_S.sfs on the specified partition.

Flash · Posted: Tue 22 Oct 2019, 11:41 Post subject:

Huh. So, does Puppy incorporate the changes from the sfs file when it boots?

stemsee · Joined: 27 Jun 2013 Posts: 2572 Location: In The Way

That would require a change to the init script to find it and load it/copy it on an higher aufs branch during boot. So no.

Fatdog allows extrasfs to be loaded at boot. And it seems to work as expected.

But it's a backup which could later be mounted and copied to a savefile/pup_rw.

nic007 · Posted: Tue 22 Oct 2019, 17:03 Post subject:

Save and boot it as an adrv?

mikeslr · Posted: Tue 22 Oct 2019, 17:54 Post subject:

Hi stemsee,

Hi nic007, "Save and boot it as an adrv?" I was thinking along the same line. But wondered if it could produce an encrypted 2fs. If so, then maybe the following:

Create a normal Savefile and 'flesh it out" including changing the Save Session interval to Never without "Ask at shut down". In other words, the only Save would be manual.

Reboot. Make no changes. But use sfs-direct-save to create a small "Blank" encrypted SaveFile. Then rename the current SaveFile as an adrv (or ydrv or...) --which are READ-ONLY-- and rename the encrypted file created by sfs-direct-save as the SaveFile. Edit Grub4dos Menu.lst to eliminate "boot pfix=ram".

The User could boot into the Puppy without having to configure it; and shutdown/reboot without being asked to Save.

The User could 'update' the "adrv" using PaDS: copy>renaming the "adrv" anything except adrv. Place it and any pet, sfs or other package in a folder. Name the folder "adrv_xxx". PaDs will combine them into an adrv_xxx.sfs.

Someone unfamiliar with Puppy would be confronted with system which wouldn't boot without the password. And a hacker couldn't modify any part of the operating system.

rufwoof · Joined: 24 Feb 2014 Posts: 3717

Interesting idea mikeslr. Given me food for thought for read/write sfs

Use cryptsetup to create a encrypted folder (actually a pair of folders i.e. data and .data ... or in the case of puppy - the entire main initial OS). Make a sfs of the closed (encrypted) version. In the rw sfs case any changes could also be encrypted (tarball piped through openssl enc ... or whatever, appended to end of sfs) - which in the Puppy model would be the changes/save folder content.

It's moderately trivial to hack a ro sfs, more so given its fixed nature. Encryption of both the main sfs and changes is a high hurdle against such modification.

Flash · Posted: Tue 22 Oct 2019, 20:08 Post subject:

rufwoof · Joined: 24 Feb 2014 Posts: 3717

Or boot from usb and load it all into ram at bootup and unplug the usb once booted. Which is what I do with Fatdog. Booting from removable media also protects the MBR, bootloader, kernel ...etc. as once booted they're also physically isolated out of harms way (and are more inclined to be a target).

I use the Fatdog multi-session usb choice for such reasons. Enables the usb to be unplugged once booted, and with save session interval set to zero, you get to choose when to save (reattach the usb).

Unlike Puppy multimedia DVD that saves to folders, Fatdog uses sfs's (one for each save). To 'defrag' those you can boot, remove all such sfs's and then run a save ... and they're all combined into a single (actually two initial) sfs. sfs-direct-save is a step in the right direction IMO as its working towards that sort of setup. And as Puppy can also load multiple sfs's at bootup, reloading those saves just needs to be ordered (layered).