SafeDesk Puts Bounties on STS Open-Source Development
Posted May 27, 2006 11:29 UTC (Sat) by ledow
Parent article: SafeDesk Puts Bounties on STS Open-Source Development
To be honest, I'm surprised how LITTLE interest this is generating and I assume it's down to some technical reason. The forums are almost empty and there's no comments on LWN.net about it despite it appearing twice on the frontpage.
This project is a good way to get a PC-independent PXE-booting Linux system up and running quickly but it has some flaws. It uses Samba instead of NFS (the initrd's etc. have been edited to load the cifs modules rather than nfs) which gives it quick access and boot times comparable if not better than NFS. However, this involves running Samba on the server machine as root (albeit read-only shares), a hideous hack that I assume is the main cause people are not using this software.
I have set this up on a spare network and the configuration instructions hold your hand all the way, but because of the Samba issue (guest logins are mapped to root), it's unnerving to use the server for any other task (you can't really have read-write shares on the same machine, for example). However, it does boot any PXE-based PC into a full linux desktop over the network without using the local hard disk but taking full advantage of local hardware (USB drives, video cards, sound cards etc.)
It works by incorporating the CIFS modules into a kernel delivered by PXE. This then mounts a read-only samba share over which it then lays a RAM read-write unionfs - that read-only share is basically an ordinary directory containing Debian with all the correct permissions (which is why I assume it needs root on Samba, because it has to read files with any permission), so effectively it's using the Samba share as a liveCD over which it lays any changes.
Any changes to the setup are simply a matter of chroot'ing to that directory on the server and making changes as root. This includes adding users, software etc. in the standard ways. When the clients next access the share, the underlying filesystem to their unionfs reflects the changes.
From a users point of view, any PXE boot results in a fully accelerated Linux desktop with whatever logins are available in the chroot environment's passwd file. Default permissions are all in place and they can't change anything on the server because it's a read-only share. Therefore, changes made by the clients (which are restricted by the permissions anyway) do not affect other clients or survive a reboot. It's as if they just booted from a liveCD containing the Debian folder. They are able to use all their local hardware (which is autodetected of course), it uses X and Gnome by default but that can easily be changed.
It comes with OpenOffice.org installed and programs load quickly once the desktop is showing. You can save to local USB disks (which I assume is supposed to be the primary method) but with a little work, you could set up a secondary Samba server and have the chroot environment modified to mount that from all the clients for saving work.
Properly seperated, this is a good project for, say, a small office or home LAN. However, the security issue prevents it being immediately used for "major" tasks. For instance, with the server running with the guest account as root and the chroot directory shared out to any SMB client that wishes to connect, it's trivial to find a way to read critical information even if you couldn't compromise the server itself or change the contents of the chroot directory shared out to client.
However, for administrators, the ease of changing the chroot environment means that you could authenticate against a different server which could store passwords and other critical information and treat the PXE-chroot environment as a quicker way of using a virtual "LiveCD" to boot the clients into a known configuration, from where you could authenticate against trusted servers and retrieve and store user files etc.
to post comments)