logoSpot's home directory moved (Fatdog64 720 onwards)

Overview

Most network programs in Fatdog64 runs as the special user "spot". "spot" is a root-surrogate, which means that it is doing things on behalf of root, but at reduced permission level. This is especially useful for network programs: in case those programs have security vulnerabilities, a remote attacker can only gain the privilege and access level of the user "spot" instead of "root" (and let's hope the machine doesn't have privilege-escalation kernel vulnerabilities that enables an attacker to become "root" from "spot" ... but we digress).

To make the restriction of "spot" effective, "spot" user only has access to a few places (otherwise, then there is no point in using spot at all). One of the few places that spot has access is, of course, its home directory. In all earlier Fatdog64, spot's home directory is /root/spot. Why /root/spot? The reasons are buried in the mist of history. Let's just say that Fatdog64 inherited that location from its most earliest days - it's one of Puppy Linux heritage that Fatdog64 still carries forward to today, well, before 720 is released.

This location of spot's home directory does indeed make it very awkward.

The whole thing that we want to protect is mainly the contents of /root, but /root/spot is inside /root, which means, in order to access /root/spot, "spot" needs access to /root too, which negates the whole protection story we painted above. Or is it not? As it turns out, no, not really. Unix permission has a way that allows spot to traverse /root to get access to /root/spot, without allowing it to read anything else inside /root. This is because Unix has a separate control to allow whether a user can read contents of a directory, or just traverse it. Previous versions of Fatdogs allow spot to traverse /root to get to /root/spot, but disallow it to list or read any files in /root.

It works, but this is not perfect. The permission control of whether a file can be read (or not), is set on the file itself - not on the directory that contains the file. This means: although you cannot see the directory contents, you may still be able to read the files in it, provided that:
a) You know the name of the file
b) The permission of the file allow it
c) You have the traverse permission to the containing directories

We need something better.

The only way to ensure that programs under "spot" user can never be able to read stuff in /root, is to close of access of /root to spot, which means to revoke all access. But this means "spot" cannot access /root/spot anymore, and thus spot cannot have its home directory located here. It has to be moved somewhere.

The spot's shiny new home directory is /home/spot.

Effect of this change

You can no longer download stuff to /root/spot. The correct place is now /home/spot.

You can no longer upload stuff from /root directly, just by giving a permissive enough permission to the file; because now spot are not allowed to traverse /root at all.

You cannot view HTML files you keep in /root or its subfolders, because browsers (by default) run as spot so they cannot read the files anymore.

In order to help you to ease the transitions, we have done the following:


So what has not changed?

Spot still has access to the Downloads folder. When running as root (e.g. from ROX-Filer), dropping files to /root/spot will still drop it it to spot's new home directory (thanks of the symlink), which spot has access to.

In the process, in order to upload stuff using the browser, the recommended way is to copy those files to the Downloads folder, and then upload from there; removing the files when upload is completed. This still works.

Some people may do the same but using /root/spot for their temporary transit - this still works too.


(Historical only) Note for existing Fatdog users

The changes above will apply for those who start with fresh savefile on Fatdog64 720.

How about those who migrated to Fatdog64 720 with existing savefile from previous Fatdog versions? They still have contents in /root/spot. Spot's home still pointing to /root/spot. How to ensure that they, too, enjoy the benefit of this better security?

While we don't officially support carrying savefile from older Fatdogs into the new one, we have provided a script which will help you. The script is called /root/make-spot-more-secure.

Launch this script (either from Terminal or from Rox), and it will guide you step-by-step to secure spot. It will create /home/spot with the proper structure, copy the files from /root/spot to /home/spot, and replace it with a symlink. You can do this yourself, but the script makes it easier. Please feel free to examine the script before running it if you feel uncomfortable.

The script is designed so that you can safitely run multiple times. It will detect there is no further need for migration if it has been completed; and will do nothing in that case. Feel free to delete this script after you've completed the migration.

Note: The script /root/make-spot-more-secure has been removed from Fatdog64 900 Beta onwards. If you think that you still need this script, what you need is to start a new savefile/savedir instead.


Some other caveats and side-effects of the migration

1. "spot" is now its own user group. It is not part of the "users" group. The reason for this change is the same as above - spot should be as restricted and un-related to any other users in the system. Thus, it is highly **NOT** recommended to run the desktop as "spot". If you want to run as non-privileged user, instead of using spot, please make a new user (fido, etc) and use that to run the desktop. (You can do this from Control Panel's User Manager or mkuser.sh from terminal).

Note: From Fatdog 800 onwards, if you enable "Move Downloads Folder" when saving the session, "spot" will be added back to "users" group when the session is saved. This is because, if your savedevice is on a FAT partition, it can only be accessed by members of "users" group. If "spot" isn't in the group then the "Downloads" folder will not be accessible. If you know that your savedevice is not FAT, then you can remove "spot" again from "users" for better security by running the command "busybox delgroup spot users".

2. While the make-spot-more-secure program helps to relocate spot's home to its new place, it does not (and cannot) help to migrate the myriad of programs that may think that spot's home is still in the old location. This is not a problem for a fresh installation, but it may be a problem from existing installation (=as in, re-using the savefile from older Fatdogs). Two prominent programs comes to mind:

a) The browser. Older package have been configured to download and print-to-PDF to /root/Downloads. This will **NOT** work anymore. You need to explicitly set a new download folder (it's in /home/spot/Downloads), and also a new target folder for print-to-pdf (also /home/spot/Downloads). If you don't, everything will seem to succeed but you will find that your files are mysteriously missing (hint: they don't, they just never get saved there in the first place because the browser cannot access /root/Downloads).

b) Samba.  It's public share folder, for older configuration, is still /root/spot. You will need to edit /etc/samba/smb.conf yourself and change it to /home/spot.

But I don't want these hassles!


Of course, all these seems to be a lot of hassle. It does. If you really don't care about this, and have a strong belief that Linux is secure and impenetrable, or just prefer convenience, there are two things you can do:

a) Edit desktop files in /usr/share/applications and change their Exec= line. If you see anything with "-spot" in it, drop it (e.g. replace firefox-spot with firefox). This will make them as user root and bypass all these "spot" issues.

b) If you can't event be bothered with that, you can always open the access to /root folder, using the command "chmod permission-code /root".

The older Fatdogs had its permissions code set to 711 (open access for "root", traverse access for all), in Fatdog64 720 its permission is now 700 (open access for "root" only).

In order of more convenience (and lesser security), you can change its permission to:

But before you do this, please know what you're doing.
We make all these changes for a reason; that reason is to put your security above everything else.