Extending the lockdown framework in GNOME and making it even more deployment friendly

One of the major features required in any kind of desktop deployment is the support for lockdown, where users are barred from performing certain actions (like, for instance, printing files, or saving files to disk). GNOME already has lockdown support in a few areas (especially the panel and the epiphany web browser). However, the file manager (Nautilus) does not have any kind of lockdown support at all, and good quality documentation and specifications for the lockdown features is also missing.
The proposed project will add lockdown features to Nautilus and to the GTK+ FileChooser (to ensure a consistent user experience, as well as complete implementation of relevant lockdown policies). The lockdown features would cover filesystem access and modification permissions. Moreover as a part of the project, I would implement a mechanism to define items which will be shown on users' desktops, such as links to common web sites, launchers for programs, or links to commonly-used files such as forms or reference material. I would also document how lockdown and preconfiguration work, which can be used as a reference for administrators and deployers. The last, but in no way the least item in the roadmap is a plan to create a spec for the proposed lockdown on Nautilus and the GTK+ filechooser (probably this should go to first :-)).
The project will involve modifying various GNOME modules (Nautilus/GTK/GNOME-VFS/etc), written mostly in C. The relevant GUI tools (Sabayon/Pessulus), which are written in Python will also be extended as and when required.

Benefits to the GNOME Project

Better deploy-ability means quicker World domination!! :-)

In LTSP (Linux Terminal Server Project) kind of deployment scenarios, where all users usually share a single filesystem exported over NFS, it is often desirable that they do not have access to any parts of the filesystem except for $HOME. Such requirements are not always implementable by using filesystem level permissions, and definition of such restriction policies at the file manager level is much more desirable.
Traditional Unix admins are usually quite comfortable with regular expressions, and providing regexp support in the filesystem access rules would garner extra points for GNOME.
In unattended/understaffed deployments (for example, in large university labs providing Internet access to the students), it is a good idea to provide links to help documents, policy documents, commonly used files/applications on the Desktop itself. It would be even more helpful if some of these links are made mandatory, ie, users will not be able to modify/delete them.
In Kiosk like situations, it is often desirable that the user do not modify the $HOME layout. Ideally they should be able to only browse the $HOME, and perform no modification causing actions. Extending Nautilus to optionally disable common filesystem modification actions like cut/copy/paste/delete would help GNOME cater to such situations.
All this work on lockdown and preconfiguration is almost useless unless you have good documentation on how to make best use of these features. The proposed Desktop Administrators' Guide to GNOME Lockdown and Preconfiguration will address this void area.

Current Deliverables

Specification of lockdown for Nautilus and the file chooser.
GConf keys which specify which parts of the filesystem that can be accessed by the user using Nautilus or the GTK+ FileChooser.
Extension of the lockdown related GConf keys mentioned above to have support for Regular Expressions, utilizing the GRegex submodule recently introduced in Glib.
Mechanism to predefine items which will be shown on users' desktops, and the ability to make them mandatory.
Mechanism to predefine items which will be shown on the Places section in Nautilus, and in the GTK+ FileChooser.
Modification/Extension of Sabayon and Pessulus to support the above enhancements.
A "Desktop Administrators' Guide to GNOME Lockdown and Preconfiguration", documenting all the lockdown features found in GNOME, as well a guiding how to preconfigure the desktop settings using tools like Sabayon. (format of the document being Docbook XML)

Possible Deliverable

To be completed only if the timeframe allows it, otherwise I continue working on these beyond the SoC.

Implement disabling of the following actions in Nautilus:
- Cut
- Copy
- Paste
- Delete
- Create new folder
- Drag & drop

Roadmap

Publish my goals to the community and get some feedback. During that time, get familiar with the internals of the modules I'll be working on, and also looking at current lockdown implementations (panel-lockdown.c in GNOME-Panel for instance). (Upto end of May)
Implement the current deliverables in the order as specified above. (Upto end July)
Integrate and test the implemented features with the help of the community and at the same time, start work on the Possible Deliverable.
From the very beginning, in parallel to the other work, I'll be working on the Nautilus and GTK+ lockdown specifications as well as the administrator's documentation, and modifying as my code (and possibly design) evolves. I will try to come up with the first draft of the spec by the middle of June, so that I can use those specs to drive my code.

Some coding/implementation thoughts

Filesystem access: I was looking at the code, and it seems that implementing the lockdown at the GNOME-VFS level would be the easiest approach to follow (since the GTK+ FileChooser seems to be using the GNOME-VFS backend in all GNOME based applications). GNOME-VFS already depends on GConf, and so, no extra dependencies are introduced in the process. I hardcoded GNOME-VFS to disallow access to /etc, and the result can be seen at http://sayamindu.randomink.org/soc/screenshot_gnome_vfs_lockdown.png. It's an ugly hack, but it does seem to work, and the relevant patch file is also available. I also managed to uncover a GTK+ bug in the process - filed as bug #419507.
UPDATE: It seems that that plan for GNOME 2.20 is to replace GNOME-VFS with gvfs. In such a situation, I would have to look at the gvfs code first and understand it before commenting on anything.
Predefining Desktop and Places items: I'm slightly confused about this one. One way to go forward is to have some kind of directory hierarchy in /etc with a folder for each profile. These folder would store the relevant bookmarks file for the Places menu, as well as the Desktop items. However, I'm not sure how to differentiate between mandatory/non mandatory items in such a situation. I would look at my mentor for ideas to help me with this :-).
Implement disabling of filesystem modification in Nautilus: The quickest way to do this is to probably disable the right click menu, the Edit menu, the File->New Folder menu item, shortcuts such as Ctrl-C/Ctrl-V and drag and drop. The Windows the Shared Computer Toolkit has an option which lets the administrator disable the right click menu in Explorer. However, I would need to seriously investigate whether this disables other required functionality for the user, and then decide on the way to go forward.
Applications related permissions: I also wanted to propose application related permissions as a part of my TODO items - where the administrator can specify applications that can be launched by the user. However, the Sun JDS developers seems to have already implemented this - the patches are at at the OpenSolaris site.

About me, and my benefits from participation

I'm a 22 year engineering student from Kolkata, India. I'm involved with a Desktop deployment project at the West Bengal University of Technology, using Ubuntu (GNOME based, of course). I'm quite familiar with LTSP (I helped implement the LTSP installation at the University Library) and GNOME on thin clients is one of the primary areas of my interest. I have started to help with the Sabayon project (bug #320589, #397742) and also wrote some example scripts illustrating how to use Sabayon from the command line, from Python scripts. I also have a script to autogenerate documentation from the Sabayon code.
Apart from deployment related stuff, I have been playing around with multimedia and GTK+/GNOME related stuff for around three years (libxine, gstreamer, etc). I developed Senpai, a distant education tool with multimedia capabilities, and Hippopotamus Streamer, a tool to do live streaming from your webcam. Both these applications have been developed in C, using libglade. Nowadays I do some work on the Exaile Media Player project (tickets #37, #09, #1).
I'm also involved with localisation (at first bn, and then, bn_IN), and I started off in the GNU/Linux world by writing a mini-HOWTO for The Linux Documentation Project (the PCTel Micromodem Configuration Mini HOWTO).
I'm comfortable with both C and Python, as well as the relevant GNOME libraries. I believe that this project would be a springboard for me to do serious contribution in GNOME (code-wise), and the learning process will make me familiar with the internal nuts and bolts of the GNOME Platform. Moreover, for the past 5 years, I have seen GNOME evolve (as a lurker in the mailing lists/IRC channels, as a (pre)viewer, as a member of the 110n team), and it has become one of the Free Software projects that is truly close to my heart. I really do want it to succeed, and better deploy-ability for GNOME means better chance of it getting used by millions of new users all around the world.

Tentative Schedule

April 11 - May 15

Publish my goals to the community and get some feedback.
Get familiar with the internals of the modules I'll be working on, and also looking at current lockdown implementations (panel-lockdown.c in GNOME-Panel for instance).
Start work on the Desktop Administrators' Guide to GNOME Lockdown and Preconfiguration.

May 15 - June 5

Specification of lockdown for Nautilus and the file chooser.
Implementation of GConf keys which specify which parts of the filesystem that can be accessed by the user using Nautilus or the GTK+ FileChooser.
Extension of the lockdown related GConf keys mentioned above to have support for Regular Expressions.
First draft of the Desktop Administrators' Guide to GNOME Lockdown and Preconfiguration submitted for review and feedback.

June 5 - June 14 (University end semester exam time)

I will not be very active during this time (except for responding to feedback, and making small changes in the code/documentation)

June 15 - July 25

Implementation of mechanism to predefine items which will be shown on users' desktops, and the ability to make them mandatory.
Implementation of mechanism to predefine items which will be shown on the Places section in Nautilus, and in the GTK+ FileChooser.

July 26 - August 10

Modification/Extension of Sabayon and Pessulus to support the above enhancements.
Final draft of the Desktop Administrators' Guide to GNOME Lockdown and Preconfiguration submitted.

August 11 - August 20

Final push (in bugzilla) to get the above enhancements integrated into the relevant GNOME modules. Do reviewing/refactoring of code if required.

August 20 - August 25

Final report (draft) writing

August 25 - August 30

Feedback from mentor on the entire project, and making changes to draft of the report.

August 31 -

Continue working on Nautilus file modifications lockdown (mentioned under Possible Deliverable)

NOTE: Regarding the file modification lockdown in Nautilus (mentioned under Possible Deliverable), I will start work from the beginning of August, if and only if the rest of the project is on schedule. Otherwise, I will start work on it only once the other things have been completed and integrated into the main source tree.

Acknowledgement

Federico Mena-Quintero, (he was the one who originally proposed the idea at live,gnome.org and in his blog. I just built upon it)