Skip navigation.
home | news feeds | archives | search | forums | submit news
Home

Summer of Code 2007 underway

Submitted by Uraeus on Fri, 2007-04-13 06:05. GNOME
GNOME

So the list of approved GNOME SoC projects is now online with a lot of interesting projects getting approved. Highlights include projects to further improve GNOME bluetooth support, Scanning support and input device hotplugging. Other interesting projects revolved around Telepathy and the new VOIP infrastructure, Pitivi improvements and Evolution. Be sure to read through the list and see whats happening.

There are of course also a long host of other projects participating in Google Soc, so if you click into the project name on code.google.com/soc you will be able to view their approved projects. Many of them are of course relevant to GNOME in various ways, ranging to improvements to applications popular among GNOME users to for instance HAL support for NetBSD enabling better running of GNOME on that platform.

Good luck to all our students and mentors as they set forth to make this the best Summer of Code ever :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

lockdown policy?

Submitted by rutulian on Fri, 2007-04-13 15:25.

Wow, all of these SOC projects are awesome! If even just half are fully completed, GNOME will benefit tremendously. The only one I raise my eyebrow at is this one,

Extending the lockdown framework in GNOME and making it even more deployment friendly
http://code.google.com/soc/gnome/appinfo.html?csaid=5B80702342ED312C

I'm not sure, exactly, how this can be implemented. It sounds like the applicant wants to just disable some Nautilus and file chooser functionality per the filesystem lockdown policy, but this doesn't really lockdown the filesystem. If the user has access to the terminal, or if an application implements its own file chooser (a lot still do), the lockdown policy can't be enforced.

If you want a filesystem lockdown policy, it has to be implemented at the filesystem level. I don't think you would need to do anything fancy. A GUI to setup multiple users and ACLs to control their access to different filesystem objects would do the trick. And integration with Nautilus (in the form of greyed out menu items) would be nice. Maybe that would be a better approach?

Re: lockdown policy? by Anonymous George (not verified)

The lockdown would actually

Submitted by rutulian on Sun, 2007-04-15 17:08.

The lockdown would actually be implemented in GNOME-VFS, so even if an application uses a custom file selector, if that selector uses GNOME-VFS

That's the whole point. There is a ton of software in common use on a regular gnome desktop that doesn't (or can be configured so it doesn't) use gnome-vfs--firefox, openoffice, gimp, etc.... The only situation where your proposed filesystem lockdown would work is where:
1) all software installed on the system is rigidly controlled--you'll have to make sure programs like firefox that optionally support gnome-vfs do, and that they do for all filesystem accesses (not just remote filesystem accesses)
2) access to the terminal is completely disabled, which requires blocking all terminal binaries installed on the system (not just gnome-terminal, see #1)--you'll also have to block ctrl+alt+F1, although I'm not sure how you would do that
3) there are no compilers or script interpreters installed on the machine (see #1)--or, since this would likely break a lot of things, every compiler and script interpreter is blocked

This removes a lot of functionality from the desktop. So if your target user is trying to do something other than writing a letter to grandma, you're asking for a lot of pain. Note on the blocking: not sure how you are going to do that. You can disable the Run dialog and the creation of launchers, but then you are removing even more functionality, and there are other ways of executing programs if you are determined enough.

So we have to get back to why you are trying to do this. Looking at your proposal...all of the scenarios listed can be accomplished with existing filesystem level controls, of course a GUI to set it all up would be nice. Any sort of filechooser level access control would be an inferior and painful solution for all of the reasons listed above. The scenario where you want to restrict access to $HOME can happen with ACLs (maybe even with standard unix permissions using sudo and multiple users), again a GUI to set it up for kiosk systems would be nice.

you can't restrict access to /etc via fs level ACLs, for example - almost all applications will break in such a situation

How is that? Unless you mean blocking read access, but you can't even do that in Windows. I'm not even sure why you would want to. The most you can do is hide it. Again, with filesystem level controls, you can prevent listing of the directory while still allowing read access to specific files. You can also block read access to specific system files, like /etc/passwd, if you think that is needed. Filtering results out of the gtk filechooser isn't going to make things any more secure.