Welcome to Kirsle.net!

Sometimes I start a graphical app from within a terminal, for instance because opening the app via a double-click doesn't do anything (for instance, if a Wine app won't start because of a missing DLL file - I can only see this error message if I try to start the app from within a terminal).

But then I want to close the terminal but still keep the graphical app running. Closing the terminal would kill the graphical app too, unless you can somehow detach it completely from the terminal.

For the example I'll run gedit, GNOME's default text editing program, from a gnome-terminal terminal window.

1) Start the graphical app from the terminal

$ gedit

2) Temporarily suspend the process with Ctrl-Z

^Z

The terminal will tell you which "job number" it has given to the suspended process. This will usually be 1 unless you have other jobs running:

[1]+ Stopped gedit

$ bg 1

4) Disown all jobs from this terminal

$ disown -h

This can also be used to detach command-line applications, too - especially if it will be a long-running process (for example, to back up a large folder over the network) and when you don't really care about its output; you just want it to continue running until it's done, but you need to close your terminal.

With no 3D acceleration, the results are the same as before: a mostly black screen, can't really do very much with it. With VirtualBox's 3D acceleration enabled, it's similar to the result I had before... very frequently the majority of the desktop (besides a box around my desktop icons) and the whole shapes of windows have that "striped" blue texture all across them.

I say most of the time because it's sometimes possible to get a window to show its true contents and become usable by dragging it around and playing with it for a bit, but the effects usually don't last very long before the window loses its textures again. The scale effect of bringing up the main menu in GNOME Shell usually fscks up all windows you have open again.

But the reason for this particular blog entry is that I also decided to test Compiz Fusion inside VirtualBox, on Fedora 12, under the same conditions as the GNOME Shell. I couldn't do this before because the beta version of Fedora 12 had some dependency issues, and Compiz conflicted with GNOME Shell; they couldn't co-exist together.

In Fedora 12 they can co-exist, and the Desktop Effects GUI window gives options to select either Compiz or GNOME Shell. Anyway, here's a screenshot. This is a real screenshot of Fedora 12 running in VirtualBox with full desktop effects active, including the 3D Cube effect.

Click for a full-size version of this screenshot

It basically relied on the fact that GNOME, KDE, and Xfce treat .desktop files specially, in the way that Windows treats .exe files specially. .desktop is the file extension of Launchers in modern desktop environments, and they used to be launchable without even requiring execute permissions first. With them you could distribute a simple .desktop file via e-mail which downloads and executes malware from the web in one easy "click-and-run" motion from the victim. Read the linked blog post for all the details.

In Ubuntu 8.10 and Fedora 10, as mentioned there, this is how GNOME treated .desktop files; in Fedora 11 (and probably more recent Ubuntu's) things are a little different. Now, .desktop files are inherently untrusted and will prompt the user when they try to execute them. The user can then mark them trusted (which requires them to try and execute them a second time), or just launch them this one time.

When a launcher is untrusted, it displays in Nautilus as a text file. Its icon is a preview of the first couple lines of the text inside the launcher file, instead of the custom icon specified for it, and the .desktop extension is displayed to the user. When marked as trusted they work as before: the .desktop extension is hidden and the launcher gets its custom icon displayed.

Anyway, when you put files into a tarball (e.g. tar -czvf), the files keep their permissions and attributes. Thus, if you put a file with execute permissions into a tarball, it keeps that permission. If extracted on any other unix system in the world, it's extracted with execute permission.

After some poking around, I discovered that the mechanism by which launchers are marked as trusted is simply based on the execute permission. When a program such as wine creates a launcher (for instance, if you just installed a Windows app that puts an icon on your desktop), the launcher is currently untrusted by default, so you'd have e.g. "Mozilla Firefox.desktop" on your desktop; it's not a trusted launcher. When you run it and mark it trusted, all that happens is that GNOME adds execute permissions to the file. You could also run chmod +x "Mozilla Firefox.desktop" in a terminal to do the same thing.

So... for the "virus" in that blog entry to still work on Fedora 11, you'd need one additional step: e-mail them a tarball containing your desktop launcher and have them extract the contents, and then run the launcher. This makes it a little bit less likely that the victim will actually run it, though, especially because if they look inside the tarball first they'll see its real file name (including the .desktop), and GNOME's archive manager won't execute it if they open it directly from inside the tarball; instead they'll get the contents of the file displayed in their text editor.

Here's a random idea that just popped into my head: to help with the security of CGI scripts, certain HTML elements in the forms can be "tagged" in various ways depending on what their function will be once submitted.

So a textarea for leaving a comment can be tagged with name="ta-comment" (ta means textarea), and an input box meant for entering user names only could be tagged with name="user-login", and an input box meant for entering numeric zip codes can be tagged name="num-zipcode".

Then, the CGI script, when it first begins parsing the query string and form parameters, can automatically apply global filters to the inputs based on their tag. This way, every input that might potentially be used to access the filesystem can be filtered so that it doesn't contain any special characters that could introduce a vulnerability in the script, but fields that are meant to be more verbatim (i.e. comment boxes) can be left largely untouched.

# Create a CGI object
my $q = new CGI();

# This will hold your script's parameters
my $args = {};

# Get all the params.
foreach my $what ($q->param) {
    my $is = $q->param($what);

    # Filter the value based on the tag.
    if ($what =~ /^num\-/) {
        # Numbers only!
        $is =~ s/[^0-9]//g;
    }
    elsif ($what =~ /^user\-/) {
        # Usernames are numbers and letters only!
        $is =~ s/[^A-Za-z0-9]//g;
    }
    elsif ($what =~ /^ta\-/) {
        # Textareas turn their line breaks into <br>
        $is =~ s/\n/<br>/g;
        $is =~ s/\x0d//g;
    }
    $args->{$what} = $is;
}

So this way, as you write your front-end HTML code and the back-end Perl, you can tag all the inputs based on how the back-end code will plan on using them once submitted, and the code that collects the parameters when the form is submitted will be sure to format them in a consistent way. So, if your web application consistently doesn't allow quotation marks or HTML code in their text boxes, you can make the CGI automatically remove these things from all your incoming fields, and then just specially tag the ones that you want to be treated differently.

It would protect against accidental oversights by the programmer, and the end user can't do anything about it either. If the text box's name is "num-zipcode", the CGI script will always remove non-numbers when submitted and the user can't do anything about it. If they try to rename it with Firebug to be "text-zipcode" or anything like that, your CGI script won't use their version because it's not named as "num-zipcode."

I think I'll try implementing something like this next time I create a new web application.

I remember that the ability to share USB devices with virtual machines used to be working "out-of-the-box" with VirtualBox and older versions of Fedora, but Fedora 11 complicates things a bit.

By default USB devices in virtual machines don't work; the menu lists all your USB devices as being greyed-out while the machine is running. It comes down to a permissions issue with the user you're logged on as. To fix:

1) Make sure your user belongs to the vboxusers group. Older versions of VirtualBox made this an absolute necessity (virtual machines wouldn't boot otherwise), but VirtualBox 3.0 seems to only create this group but not actually require your user to belong to it for the most part. Update: with current VirtualBox, this is all that's required; USB should be working after you do this and log out and back in. If not, continue reading.

2) Create a mount point directory for usbfs (I did mkdir /usbfs as root).

3) Edit /etc/fstab to add a line that mounts usbfs, giving the vboxusers group write permissions to the mount point. In my case vboxusers had a group ID of 501; check in /etc/group to see what your group's GID is:

# VirtualBox USB support
none  /usbfs  usbfs  rw,devgid=501,devmode=664 0 0

Now, you can either reboot or run mount -a as root (to reload the data from /etc/fstab). If you had to add your user to the vboxusers group because it didn't already belong to the group, you'll need to log out and back in again.

And now your virtual machines can access the USB devices.

I set cuvou.com to redirect all links for regular pages to their counterparts on the new site, and to preserve HTTP referrer information while it's at it (so I can continue to see which Google queries link to my site, for instance). My sites have always been programmed to ignore referring URLs that belong to the same domain (so clicking a link within the site doesn't log the referrer because it would be rather pointless to do so).

But now that the domain has changed, referring URLs from cuvou.com show up in kirsle.net's logs, and it revealed something interesting about the spam bots:

They love my guestbook page. They probably find it via search results for the word "guestbook." Spambots look for guestbooks specifically because they usually tend to contain e-mail addresses, which the bots can add to their list of victims.

My guestbook has no e-mail addresses but instead resembles a blog comment thread... but they don't know that.

Anyway, the interesting thing is, on these requests, the spam bots send the referring URL as being exactly the same as the URL they requested. So their requests look like this:

GET /guestbook.html HTTP/1.1
Host: www.cuvou.com
Referer: http://www.cuvou.com/guestbook.html

The effective result is that cuvou.com's guestbook page is the #1 referring URL (also the #2 and #3 top), because of how popular that page is with the spambots.

Maybe I should set up a spam honeypot on that page and trick them into downloading an infinite number of bogus e-mail addresses that go nowhere to flood their databases with fake e-mails and waste the spammers' time...

There are still some things left to do with it and I need to rewrite a couple of pages, but for the most part it should be fine for now. All the old links on cuvou.com now redirect to kirsle.net; let me know if there are any broken links or anything like that.

I'll post a more thorough blog post about this when I polish up the site a little bit and have time to write about it.

Update: added a traffic-logging plugin, which replaces Cuvou::Traffic on the old site and is better integrated now.

This is a sequel to my rant about GNOME Shell. I decided to back up my claims with an experiment.

Installing gnome-shell in a virtual machine with no 3D hardware acceleration.

Every single desktop environment that exists right now will run just fine in a virtual machine with no 3D hardware acceleration: XFCE 4.6 and older; KDE 4.3 and older; KDE 3.x and older; GNOME 2.26.3 and older; LXDE; and of course all of the desktop-less window managers (IceWM, et cetera).

GNOME 3.0, I claimed, with its GNOME Shell, will be the first desktop environment that will not run unless the user has 3D hardware acceleration, and that there is no fall-back. Here is the proof:

No Guest Additions; No 3D

* Fedora 12 Alpha (11.92 Rawhide)
* VirtualBox 3.0.6 r52128 (2009-09-09)

Let's launch it!

Getting ready to launch GNOME Shell

And... what happens?

Umm...

Hmm...

Let's put on the dumb end user hat and say Joe Average installed Ubuntu 10.10 which might come with GNOME 3.0 and GNOME Shell, he hasn't installed his nvidia drivers yet because they're proprietary and Canonical can't legally include them with Ubuntu, and he logs on and sees THIS. He's lucky that X11 didn't crash entirely and send him back to the login screen, but nonetheless he can't see anything. He can't see Firefox to start browsing the web trying to find a solution to this problem.

Okay, let's move on...

Guest Additions, No 3D

Exactly the same.

I won't post screenshots because they look just like they did the last time. I get a mostly black, unusable desktop.

Of note however is that the terminal printed this upon starting the GNOME Shell:

OpenGL Warning: Failed to connect to host. Make
sure 3D acceleration is enabled for this VM.

Enabling 3D Acceleration

I've personally not used it. But it is known to be buggy; VirtualBox labels it as "experimental"... well, here's why:

Start the shell...

Uh...

This looks promising...

In this experiment, even with 3D acceleration by the virtual machine, GNOME Shell is not usable. Again, though, VirtualBox's 3D acceleration is still in the "experimental" phase. It probably doesn't work a whole lot better with Compiz Fusion, either. Plus my video card might just suck (VirtualBox basically passes the guest's OpenGL calls directly to the host's video card).

But the thing to take away from this is:

• Desktops that work with basic video drivers:
  • GNOME 1.x series
  • GNOME 2.x series
  • Xfce 4.6 and older
  • KDE 3.x series and older
  • KDE 4.x series and older
  • LXDE
  • All window managers
• Desktops that don't work with basic video drivers at all:
  • GNOME 3.0 with GNOME Shell
  • (can you hear the crickets? yes, GNOME 3.0 stands alone, all by itself, in this category. sad. :( )

Now let's see if the GNOME dev team can turn this around in the next year (doubtful; they all come off to me as a bunch of eye-candy-obsessed children who'd rather snazz up the desktop because they think it's "cool" than to worry about things like usability, functionality, or accessibility... and with absolutely no thought given to the user experience, and no usability studies done, etc.).

GNOME Shell for the lose.

The new one seems to be headed in the right direction, though. I named it Siikir, because I plan on adapting it for a multi-user website by the same name after I've first built it so it suits me on my single-user websites.

The main thing that sets it apart from any failure of a CMS I've built in the past is that this one is completely abstract and plugin-oriented... so, the main Perl module that gets loaded doesn't really do anything itself, it only manages the loading and controlling of other plugins... literally everything else (page controllers, user management, sessions, etc.) are all delegated to extra plugin modules.

The general idea is this: if I want to make an ajax front-end that tests whether a username is taken or not, why should the code for that be required to load all the code for pages, photo albums, profiles, blogs, etc.? All it really needs to do is load the one plugin that manages users, and ask it if the user is taken. Simple. So that's what this new CMS structure allows for.

Since I'm liking it so far, I just might release the code after I'm doing working on it. Maybe.

Anyway, it's getting close to completion. Page management, users, profiles, and photo albums are all completed (unlike the photo albums on cuvou.com, each user can make their own collection of photo albums). All that's left is programming a blog back into it, and then I'll be migrating everything on this site over to the new code.

I'll also be changing the domain name; this site is gonna be moving over to kirsle.net with the switch. All the old links to specific files on this site will be redirected to the same files on the new domain, for a while, until Google forgets about the old URLs... then I may use cuvou.com for something else.

Half a year ago the roadmap for GNOME 3.0 was announced, and it involves a new window manager called GNOME Shell. They plan to have GNOME 3.0 ready for public consumption in 2010, around the release of Fedora 13. I tested the GNOME Shell back then and it was awful; since then, it hasn't improved a lot, either. And I'm not optimistic about where it's headed; I think GNOME 3.0 is going to be a terrible, terrible mistake.

If you aren't aware, GNOME is a desktop environment for Unix, and is the default desktop environment for both Fedora and Ubuntu. The other major desktop environments are KDE and Xfce.

GNOME has been said to resemble Windows 98 - true, its default theme is pretty gray and boring, but GNOME is flexible enough that it can be made to look just like OS X or Vista or anything else.

The KDE desktop environment looks an awful lot like Windows as well. KDE jumped from versions 3.x up to 4.0 about a year ago, and KDE 4.0 looks a lot like Windows 7. But on the whole, the desktop still looks and acts the same; KDE's version jump was a natural evolution of its desktop, not a complete change to something completely new and unfamiliar.

GNOME, not wanting to be 1-upped by KDE's version jump, decided they'd bump GNOME 2.x up to version 3.0 -- and entirely redefine the desktop metaphor while they're at it. GNOME 3.0 with its GNOME Shell has almost nothing at all in common with GNOME 2.x.

Here is a relatively recent article about GNOME Shell, so you can take a look.

But that's not why I dislike it. I just thought I'd give some background first. This is why I dislike it:

GNOME Shell requires 3D hardware acceleration. What? Let's compare the current desktop environments: Xfce 4.6 and older, KDE 3.x and older, KDE 4.0, and GNOME 2.x and older... all of these desktops can be run on bare minimal video hardware. You know how Windows Vista, and Windows 7, have "Basic" themes? If you run Vista or 7 on a computer that either doesn't have a kickass video card, or you simply just don't have the drivers installed yet, you get to use the "Windows Basic" theme. Windows has a fall-back to Aero.

But GNOME 3.0 will have NO such fallback. If your video card sucks, or you don't have the drivers, you can't use GNOME 3.0 at all. What will you see? You'll see the X11 server crash and leave you at a text-mode prompt. You will have NO graphical user interface at all; you'll be stuck in text-only mode, because your video card must be kickass for GNOME Shell to load.

Most people have ATI or Nvidia cards, you say? Well, it's well known that ATI and Nvidia have proprietary, closed-source drivers; the companies simply refuse to open up their video drivers as free software. And because Linux is a free and open source operating system released under the GNU General Public License, Linux isn't legally allowed to include ATI or Nvidia drivers "out-of-the-box."

So, when you pop in your Ubuntu or Fedora CD to install it on your computer, the installed operating system can not legally contain Nvidia or ATI drivers. Without the drivers, your video card can't do 3D acceleration. If you were on Windows Vista or 7, you would see the Windows Basic theme; if you're on Linux with GNOME 3.0, you'll see NOTHING! You'll be at a text-mode login prompt, and when you log in, you'll be at a text-mode bash prompt. No graphics, no windows, nothing but text.

This wouldn't be the end of the world for me personally, but then again I know a great deal about Linux. I would be able to install third-party software repositories and install the Nvidia or ATI drivers all at the command line; or at least I would know how to install an alternate desktop environment such as Xfce so that I could get a GUI and then fix the video problem manually. But the average user, or newbie to Linux? They'll be stuck.

I'm curious to see how Canonical (the company behind Ubuntu) is going to deal with this. Are they going to stick it out with GNOME 2.x and ignore GNOME 3.0? I imagine that's quite a likely scenario. Because consider this:

Ubuntu is known as the newbie-friendly Linux distro. It's the easiest one to get set up and running, it's easy to use, and when you log in for the first time it even asks you if you'd like to install some proprietary hardware drivers. Ubuntu can't legally install these automatically but it makes it easy for the user to install them afterward.

What if Ubuntu upgrades to GNOME 3.0, a new user installs it on their computer, and the new user can't even get the desktop to load? They have an ATI card and they don't have the drivers installed, and therefore GNOME 3.0 absolutely will not start because it absolutely requires hardware acceleration. They're a complete newbie to Linux, they know nothing about the command line, but they're stuck at a text-mode prompt. Know what they'll do? They'll switch back to Windows and never be fooled again when somebody wants them to give Linux a try!

Of smaller importance, by reinventing the wheel, the GNOME developers are basically starting over from scratch almost. This means that some of the more complicated problems that the GNOME dev team have tackled in the past may come back. Dual monitor support, for example. The jump to 3.0 is quite likely going to be a large step backwards for the GNOME desktop environment.

I am not a fan of where GNOME is heading. And if the GNOME dev team end up fscking this all up in the end, I'll just be forced to use a different desktop environment. Although, I really don't want to have to resort to that...

I love GNOME 2.x. I can not stand KDE. KDE is just completely annoying to use. Xfce isn't too bad; it shares a lot in common with GNOME (they both use the GTK+ GUI toolkit)... but Xfce feels far behind GNOME 2.x - it feels clunky and old-school, and it lacks certain features that GNOME 2 has, such as integrated dual monitor support; for dual monitors in Xfce you'll have to resort to Nvidia's config tool (if you have an Nvidia card), otherwise you're screwed.

Xfce still has a year to get better, and GNOME 3 still has a year to not completely suck in the end. If GNOME 3 sucks and Xfce is still so clunky, I may even just be forced to abandon the Linux desktop altogether and go back to Windows. :(

Take a lesson from Windows (and literally every single desktop environment in Linux), GNOME 3.0 - don't make 3D acceleration an absolute requirement, and include a fallback version for basic video drivers. Otherwise a really good chunk of your user base will move on to other desktops, or move back to Windows. And if you keep this up, Canonical and Red Hat may even just have to drop you completely as their default desktop environments in their distros, for making life too complicated for the end users.