- INCOMPATIBLE CHANGE: renamed urlLauncher resource to url-launcher.

So, to fix this just change URxvt.urlLauncher: browser line to URxvt.url-launcher: browser in your ~/.Xdefaults.

$ git push remote-name :branch-to-be-deleted

or alternatively with

$ git push remote-name --delete branch-to-be-deleted

With the first try I got the compiling errors

dwm.c:33:28: fatal error: X11/cursorfont.h: No such file or directory
compilation terminated.
make: *** [dwm.o] Error 1

and

dwm.c:40:37: fatal error: X11/extensions/Xinerama.h: No such file or directory
compilation terminated.
make: *** [dwm.o] Error 1

In the dwm README it says:

Requirements: In order to build dwm you need the Xlib header files.

so that’s where the rub is. The particular  packages you need in Debian are libx11-dev and libxinerama-dev, install them with

$ sudo apt-get install libx11-dev libxinerama-dev

and you’re set.

urxvt*termName: rxvt-256color

or

urxvt*termName: rxvt

or whatever. The terminal acts nicely with screen and ncurses, and I haven’t run into any problems thus far. But note that generally speaking lying about your terminal’s capabilities is a stupid idea.

A while back I remembered I still hadn’t done it and decided it was about time to get my hands dirty. It turned out to be quite trivial, after all.

If you don’t already have a gpg key you should probably find another resource on how they work, but in short you can get one by having gpg installed and running

gpg --gen-keys

and following the instructions.

Once you have the key associated with that one email address (or identity) you can add another one simply by first issuing

gpg --edit-key <key-id>

If you don’t know what your key-id is, you can see it in the output of

gpg --list-secret-keys

You should now be looking at a gpg> prompt. Command

gpg> adduid

and go through similar process as you initially did when creating the key. After you’re done and back at the gpg> prompt it should list both of your identities. If there isn’t an asterisk beside your new key, set it with

gpg> uid #

where # is the number of the new uid in your list. The asterisk indicates that the commands you take next operate on that uid. Now, say

gpg> trust

and assign the new key to be ultimately trusted (you’re a decent fellow, aren’t you?!). Now all there is to do is to exit with

gpg> save

and you’re all done.

pinentry-curses: no LC_CTYPE known - assuming UTF-8

It has probably something to do with me not running gpg-agent daemon, or something. Anyway, setting GPG_TTY with

export GPG_TTY=$(tty)

fixes the issue, and the ncurses prompt for the password appears as it is intended.

Recently I’ve migrated away from MySQL, into PostgreSQL. For logging links to a MySQL database there was Riku Voipio’s srcipt, mysqlurllogger.pl, but I couldn’t find a ready-made script for logging them to PostgreSQL database so I rolled one myself.

The script isn’t very feature-rich, but it gets the job done. It has one twist, though, it fetches the title of the linked page. The feature comes with a cost, as it needs the LWP perl module to be installed. Another requirement for the script is naturally the PostgreSQL database driver, DBI. Also, see the edit below.

The script expects a table called “links” defined more or less like this:

id: integer primary key, with a sequence for auto-increment
channel: text
time: timestamp
nick: text
link: text
title: text

Once you’ve created the database and meet the requirements, drop the script to you script folder (most likely ~/.irssi/scripts/),  insert your database name, username and password in and load the script in irssi with /load urllogpg.pl.

The script can be found here*. It is released under simplified BSD-licence, so… As RMS would put it, happy hacking!

Edit: Actually now, after a bit more testing, it seems automatically fetching the page titles may not a good idea. Irssi handles scripts in the same thread as the core logic, so while waiting for the scripts to be run irssi otherwise stops any other activity. For title fetching this means that if the connection to host of the web page times out (or the page is huge/the connection is poor) the script takes an awful lot of time to return. During this time irssi is unsable and the connection to the irc server may even time out.

I’ve now disabled the feature by default, but it’s very easy to enable in the script.

tl;dr: think if you really want to enable the title fetching.

* Edit 2: This is now moved to github.

The most common form of the fork bomb is

:(){ :|:&};:

Entering that to your terminal most likely will cause your machine to freeze as it chokes on insane amount of processes.  Despite of looking a bit cryptic to untrained eye, it’s really a very simple piece of shell script. Let’s take it apart, now.

:() { ... }

This construct is used to define a function. A function also needs a name, which comes before the parenthesis i.e. my_awesome_function() { return 0 }. So in this case, where we have :(){ …} we define a function called :.

:|:&

Now, this is the contents of the function. What it does is call the function : (itself) and pipe the result to the function :. So in effect the the function calls itself twice. The ampersand means the function call is moved to background so the child processes couldn’t get killed.

;:

; is there only to tell the parser that the function definition ends here, and what follows is a new command. It’s only needed because we want to keep the bomb as a one-liner. The last character, : is of course the command to start the bomb: call the function we just defined.

There’s no magic there, it’s just a regular recursive function. Only that it doesn’t terminate, but starts instantly eating up more and more of your system’s resources until the machine freezes. To make it look more like regular shell script it could be re-written for example like this:

bomb() {
    bomb | bomb &
}
bomb

I don’t recommend running that on your local machine. Even if a hard reset wouldn’t harm your machine it never does any good, either.

Protective measures

Since the fork bomb works by spawning processes, you can shield your system against it by limiting the amount of processes a user can simultaneously have.

On a Linux system you can do this by editing your /etc/security/limits.conf file. There’s probably some kind of template for you to take example of. What you want to limit is nproc:

harski hard nproc 100
@users hard nproc 50

The target whose attributes you want to target can be a single user (like on the first line) or a group (the second line). If it’s a group, you need to indicate it by prepending the group name by @. “hard” on that line means it’s a hard limit. The other possible value would be soft limit (only warns about having too many processes).

It also takes wildcards and can enforce limits to many more resources than just the number of processes, take a look at its man page for more information.

Besides the question of how to recover the password of a local machine this in my community spawned also discussion on how would one distribute for example his email password to someone else if he died. Email in particular would be a resource that would be valuable to have an access to after its primary user is gone, to shut down it and other services linked to it, if for nothing else. (Turns out there are services for distributing your passwords [for example deadmansswitch], if you trust them enough.)

Anyway, this post is about recovering root password in case you forgot it or happen to acquire dead man’s laptop or whatever. I have collected here four different ways to possibly gain root access to the machine without relying on any software exploits, some of them more convenient than others. After you have a root (or in some cases just write) access to the disk, you can go and edit /etc/shadow manually, or change it with passwd.

Note that all these rely on the fact that the media the target system is on is unencrypted. If the disk is encrypted and you don’t have the password, getting the data out is pretty much a lost cause.

Runlevel 1

Probably the easiest way to go about this is booting straight to runlevel one. It is a single user mode for admin tasks. Booting a linux kernel to runlevel one is as easy as appending “1″ (without the quotes) to your kernel parameters in your bootloader.

This method is very easy to do, but in practice it has a couple of “defects”. Defects as in security measures involved. Firstly, on some systems booting the kernel in to runlevel one doesn’t drop you immediately to a root console, but instead prompts you for the root password which makes this approach a dead-end. This is the case in for example my Arch Linux install.

The second problem can be giving the kernel the “1″ -option. If the bootloader is locked for editing you simply can’t hand it to the kernel and the system will boot up as it always does. In this case the only way to edit the boot menu you’d need to log in as root and then edit the menu… which again puts us to a dead-end.

init=/bin/bash

Trying this method out is pretty similar to runlevel one trick above, but circumvents the first problem in it. Adding init=/bin/bash (or init=/bin/sh or whatever) to the kernel options in you bootloader instructs the kernel to run the specified command first, instead of the usual /sbin/init. This drops you straight into a root shell, and you should see your filesystem just fine. One thing to note here is that the filesystem is now mounted as read only, so to change the root password you first need to remount the fs with read/write access:

mount -o remount,rw / 

You are now ready to modify /etc/shadow. As you can see, this too relies on being able to edit the kernel options in your boot loader, which can potentially render this method useless.

Booting a live-cd

Pretty trivial, eh? Insert the media containing the live os, boot it, mount the disk in the machine and edit it accordingly. But! For this to work you need to be able to select the first boot device. If the order is set and BIOS is password protected, you have a minor bump on the road. “Fortunately” as this method already assumes physical access you can open the case and remove the BIOS battery. This should reset the BIOS and you are free to edit it again!

Taking the disk out and modifying it on another system

The title says it all. Since we already have access to the machine physically, and don’t want to bother ourselves with downloading live systems and burning CDs, simply:

• take out the disk
• plug it in your own machine
• boot the system normally
• mount the foreign disk
• edit disk accordingly

What can we learn from all this from security’s point of view?

We can turn this whole scene upside down, and take a look at what measures you could take to prevent someone from gaining root access to you box.

The first two methods relied on being able to modify the kernel boot parameters. There’s a simple solution for that: lock it from modifying. There almost certainly is an option for that somewhere in the configs.

The first one also relied on being able to enter runlevel 1 without prompting the root password. In Arch asking for password is achieved by having “su:S:wait:/sbin/sulogin -p” in /etc/inittab, but I don’t dare even try giving a general instructions on how you should do this. Consult your OS manual or so ;) Besides, locking the boot loader prevents also entering to runlevel 1 in the first place so this isn’t an issue, and not locking it still makes it possible to use the init=/bin/bash -parameter instead of this.

Now that the bootloader is secure, let’s move on to BIOS. Set a password for it, and see that the first device the machine looks for something bootable isn’t a removable media like a cd-device or USB port. Some BIOS’ have a function for selecting the bootable device just for that time, by hitting some key before POSTing. Disable this, too.

All in all: physical access is a bitch. If you have a machine you want to keep safe? Don’t let anyone near it. All the tricks above rely on getting physical access to the machine. If your disk is not encrypted and someone gets close enough to touch your machine there’s nothing that will protect your data from being compromised.

So as the last point: encrypt the disks on machines that other people might get to. Laptops are prone to stealing and it would be a child’s play to get your data from there if the disks are unencrypted.

The pseudocode is formatted with algorithm, algorithmicx and algpseudocode packages. The non-formatted text is achieved with alltt and striked out text with ulem package (\sout command). And who could do without amsmath. Get the packages somewhere if you lack them.

The exam document class didn’t support leaving some of the questions out (a feature not really needed while making exams), so I included a hack for it, \skipquestion. It allows you to answer questions 1 and 4 while keeping the question numbering sane. See the template for example, it’s all there.

Example of what the result pdf could look like is here, and the template can be found here.

Note: To get the page numbering right you might need to run latex a couple of times.

Update

Documentation for the algorithms package (usable commands, examples etc.) can be found at http://mirrors.ctan.org/macros/latex/contrib/algorithms/algorithms.pdf.

Also, as discussed in the comments, the linked template is designed for version 2.4 of the exam package and might not even compile with older version (Debian stable users beware! ;).