Solution To Problems With Certain Unix Conventions
SkulkBait
Join Date: 2003-02-11 Member: 13423Members
Join Date: 2003-02-11 Member: 13423Members
<div class="IPBDescription">Or, how to make the FHS **** its pants</div> I've often bitched about the way Linux (and Unix systems in general) do certain things. Of course I've also bitched about similar problems with Windows, but Windows isn't flexible or free (as in freedom) enough to fix IMO. So after bitching about the various problems, among which are:<ul><li>Incomprehensible standard directory names</li><li>Decentralization of program components</li><li>Lack of ability for non-root users to install software (without recompiling)</li><li>Dependancy hell</li><li>Tediousness of software uninstallation</li></ul>one day, I decided to stop bitching and try to do something about it. After a spending a good deal of time thinking (I'm ashamed to admit just how much), I came up with what I believe is a reasonable solution to problems 2, 3, 4 (sorta), and 5. Before I go into the details, I'm going to list the pros and cons of my solution vs the classical 'package manager' solution:
Pros:<ul><li>Users can install software wihtout root privilages</li><li>Clean and simple installation and uninstallation of programs</li><li>Program components centralized</li><li>Can use existing binary packages, requires no recompiling</li><li>Doesn't require any software not yet in existance</li></ul>Cons:<ul><li>A user may have more than one copy of the same library installed at one time</li><li>Is not as quick to use in a commandline environment</li><li>May have security issues I've not yet thought of</li><li>Doesn't fix problem #1</li></ul>Ok, so now, wihtout further ado, the solution:
Anyone whos heard me rant about Linux has heard me rant about <a href='http://rox.sourceforge.net/phpwiki/index.php/AppDir' target='_blank'>AppDirs</a>. I love the concept, and since this solution hinges on AppDirs I'll breifly explain them before moving on. AppDirs are self-contained programs. In general an AppDir contains a program's binary and any resources. It does not contain saved user data or configuration files. AppDirs can be copied or untarred into a directory to be installed, and deleted to be uninstalled.
In my solution, AppDirs using the <a href='http://rox.sourceforge.net/choices.html' target='_blank'>Choices</a> system would become the favored method of program distribution. Any small, infrequently used libraries depended on by an AppDir would be included in the AppDir to avoid dependancy hell. OK, you say, but what about the rest of the system? It doesn't make sense to package <i>everything</i> as an AppDir. And strictly speaking, no it doesn't. However, with a slight modification, and a different term to avoid confusion, the AppDir concept can be modified to create what I'll call Frameworks. A Framework is basically just an AppDir whos AppRun script has three functions: Activate, Deactivate, and IsActive. Activate would create symlinks from the standard hierarchy (/bin, /usr, /etc...) to the respective locations of the various files that would normally be installed in those directories. I can hear you now, "By god man, if users had write permission to those directories...", but just hold on, I'm getting there. Deactivate, obviously, would remove those symlinks. Note that unlike AppDirs, Frameworks must be deactivated before they can be uninstalled or moved for obvious resons. IsActive would exist for integration into the file manager such that when a user moves/deletes a Framework, the filer can run the IsActive and warn the user before continuing the move/deletion if it is still actived.
Ok, but what about the write permissions on the base filesystem? This is the part that brings it all together. What we do is, when the user first logs in we create a temporary directory off in some predetermined location, /userland for instance, with the permissions like 1755. Then we use the kernel 2.4 feature "mount --bind" to mount the root filesystem in a subdirectory of this newly created directory, at /userland/User/systemroot/ say. Then we create a subdirectory for each of the directories in / inside /userland/User, and symlink the files in the respective directories under /userland/User/systemroot (realative symlink). Since those symlinks were created by root, and were created in a directory with the "sticky" bit set, the user will not be allowed to remove or write over those symlinks (this is a Linux only convention AFAIK). You can probably see where I'm going with this by now. The next step is to chroot into /userland/User and continue the login process as normal from there.
After all this any number of user aiding conventions can take place, such as automatically running Activate on any Frameworks in the ~/Startup directory. The more I've thought about it the more I like this solution, though I have probably not taken everything into account, which is why I posted it here. I know there is at least one other Linux user on this forum (hi Tailsin) and I didn't feel like subscribing to an mailing lists or anything just yet. Yeah, I'm lazy, sue me. Anyways, as soon I as get around to finding the solutions to some other problems, I'll probably be making a mini-distrobution centered around this method.
Pros:<ul><li>Users can install software wihtout root privilages</li><li>Clean and simple installation and uninstallation of programs</li><li>Program components centralized</li><li>Can use existing binary packages, requires no recompiling</li><li>Doesn't require any software not yet in existance</li></ul>Cons:<ul><li>A user may have more than one copy of the same library installed at one time</li><li>Is not as quick to use in a commandline environment</li><li>May have security issues I've not yet thought of</li><li>Doesn't fix problem #1</li></ul>Ok, so now, wihtout further ado, the solution:
Anyone whos heard me rant about Linux has heard me rant about <a href='http://rox.sourceforge.net/phpwiki/index.php/AppDir' target='_blank'>AppDirs</a>. I love the concept, and since this solution hinges on AppDirs I'll breifly explain them before moving on. AppDirs are self-contained programs. In general an AppDir contains a program's binary and any resources. It does not contain saved user data or configuration files. AppDirs can be copied or untarred into a directory to be installed, and deleted to be uninstalled.
In my solution, AppDirs using the <a href='http://rox.sourceforge.net/choices.html' target='_blank'>Choices</a> system would become the favored method of program distribution. Any small, infrequently used libraries depended on by an AppDir would be included in the AppDir to avoid dependancy hell. OK, you say, but what about the rest of the system? It doesn't make sense to package <i>everything</i> as an AppDir. And strictly speaking, no it doesn't. However, with a slight modification, and a different term to avoid confusion, the AppDir concept can be modified to create what I'll call Frameworks. A Framework is basically just an AppDir whos AppRun script has three functions: Activate, Deactivate, and IsActive. Activate would create symlinks from the standard hierarchy (/bin, /usr, /etc...) to the respective locations of the various files that would normally be installed in those directories. I can hear you now, "By god man, if users had write permission to those directories...", but just hold on, I'm getting there. Deactivate, obviously, would remove those symlinks. Note that unlike AppDirs, Frameworks must be deactivated before they can be uninstalled or moved for obvious resons. IsActive would exist for integration into the file manager such that when a user moves/deletes a Framework, the filer can run the IsActive and warn the user before continuing the move/deletion if it is still actived.
Ok, but what about the write permissions on the base filesystem? This is the part that brings it all together. What we do is, when the user first logs in we create a temporary directory off in some predetermined location, /userland for instance, with the permissions like 1755. Then we use the kernel 2.4 feature "mount --bind" to mount the root filesystem in a subdirectory of this newly created directory, at /userland/User/systemroot/ say. Then we create a subdirectory for each of the directories in / inside /userland/User, and symlink the files in the respective directories under /userland/User/systemroot (realative symlink). Since those symlinks were created by root, and were created in a directory with the "sticky" bit set, the user will not be allowed to remove or write over those symlinks (this is a Linux only convention AFAIK). You can probably see where I'm going with this by now. The next step is to chroot into /userland/User and continue the login process as normal from there.
After all this any number of user aiding conventions can take place, such as automatically running Activate on any Frameworks in the ~/Startup directory. The more I've thought about it the more I like this solution, though I have probably not taken everything into account, which is why I posted it here. I know there is at least one other Linux user on this forum (hi Tailsin) and I didn't feel like subscribing to an mailing lists or anything just yet. Yeah, I'm lazy, sue me. Anyways, as soon I as get around to finding the solutions to some other problems, I'll probably be making a mini-distrobution centered around this method.
Comments
But that would mean I'd have to subscribe to the ROX mailing list, I probably will eventually, after I work out a few more issues.
Oh, I don't know if it was clear from my initial post, but Frameworks are not just repackaged packages. They are much larger and typically would include all the packages commonly used for their purpose. For instance, the GTK+ 2.0 package would include all the GTK+ 2.0 X libraries, shared resources (like the default theme), the more common engines, and probably a GTK theme chooser as well.