Disable backup / restore (persistence layer) completely

[ashfame]

Hi Paul, I am building an air-gapped device running on an immutable/ephemeral operating system, hence stringent needs of specific behavior.

Right now, I only want to change bits to make it work as I require. Having my own program packaged as extension & need of display server + webcam support etc, I don't mind using extensions at all, unless you can give me a reason why I shouldn't do things the way I am doing

Not doing automatic backups would not prevent someone manually doing a backup and that would write to your card.  You would need to either remove the backup programs, or change the ownership of the files such that you cannot run them.  However security on TC is not meant for higher security.  For example, user tc is automatically logged in, and user tc has passwordless sudo access.  With sudo access someone can easily mount the boot partition and change all of your bootcodes.  To change all of this behavior would require editing files that are contained in the initrd.  Hence my comment to remaster it.

Good point, but essentially not applicable in my-use case as I would run application in a kiosk mode (1:1 relation for every device with the user, not a public kiosk) with no option of looking around. From what I have heard, its possible to even remove right click context menu so curious users can't get out if they wanted to. Nothing gets stored on the storage medium ever. I have disabled swap, 2nd partition would be auto-unmounted upon boot. Also, no data is actually stored on the storage medium other than the OS + application. Sensitive information is restored in, once it boots up, so unless its the intended user, nobody can do anything even if they physically steal the device in a powered-off state.

And perhaps for some of the customizations, I will be editing files that are in partition 1, which is by definition a remaster, I suppose? I am slowly approaching towards the required behavior step by step, figuring out as I go.

I totally get where you are coming from though. And thanks for raising your concern. If you can still see some concerns, please highlight them, so that I can either amend ways (this is my first time diving this deep into OS layers) or explain why that isn't a concern

[ashfame]

Hi ashfame
Those are both Linux system commands. No backup will be performed by running either one of those.

Oh, I see. I thought the backup is linked to a shutdown script of some sort. I guess it then comes down to how my OS would be powered off. And since my application would run in a kiosk mode, that's where I would provide the shutdown option either explicit or inactivity based.

Wait a minute. Since I have always used those commands and never the UI option. I did see the "backing up" message on the screen at shutdown until I used "norestore" bootcode.

I suspect "norestore" does alter the backup behavior as well. Anyway to confirm this?

[Juanito]

The "norestore" boot code prevents an existing backup from being restored - I don't believe it prevents a backup from being made.

The tinycore script for shutdown/reboot is called with "sudo exitcheck.sh"/"sudo exitcheck.sh reboot"

[Rich]

Hi ashfame

... Wait a minute. Since I have always used those commands and never the UI option. I did see the "backing up" message on the screen at shutdown until I used "norestore" bootcode. ...

If you execute these commands:

Code: [Select]

tc@E310:~$ ls -l `which poweroff`
lrwxrwxrwx 1 root root 14 Jun  9  2019 /sbin/poweroff -> ../bin/busybox
tc@E310:~$ ls -l `which reboot`
lrwxrwxrwx 1 root root 14 Jun  9  2019 /sbin/reboot -> ../bin/busybox
tc@E310:~$You should see they are linked back to  busybox  which is not a Tinycore specific component. It knows nothing about backup or restore.
It exists in many different Linux distros. I would not be surprised to see a list of available commands if you opened a terminal on your
Ubuntu box and entered  busybox.