cd is fancier than you think!

I was doing something-or-other today, when I had the urge to run "help cd".  What I found changed my life.  I will never cd the same way again.  It was so life-changing I'm taking a short break from my PLDI paper, which is due in about a week.

Apparently, there's this environment variable $CDPATH which has a list of places that cd searches for the name of the folder you specified.  For example, if you have folders like

cs242
cs300
cs1337

inside your ~/school folder, and you set CDPATH=~/school, then typing "cd cs242" will take you to ~/school/cs242, no matter what your current working directory is.

But now, I have this problem: what if there are some folders in ~ that I visit often, and others that I don't want to accidentally go to (or have short names, like ~/tmp).  Symbolic links to the rescue!

Create a folder like ~/.cddir.  Inside ~/.cddir you can create symbolic links to any folder you would like to go to.  Then add ~/.cddir to your path, and you're set!

There's one more bit of awkwardness.  If you have a symbolic link like

~/.cddir/school -> ~/school

and then you do "cd school", you'll end up in ~/.cddir/school, which isn't what you really want, because if you do "cd ..", you would prefer to be in ~, rather than ~/.cddir.  "help cd" comes back to the rescue and advises to use "cd -P" instead.  This fixes the issue.  The easy thing to do is make this an alias in your .bashrc.

To recap: go into your .bashrc and add the following:

alias cd='cd -P'
export CDPATH='~/.cddir'

Then:

cd ~
mkdir .cddir
cd .cddir

and add symbolic links like

ln -s ~/school school.

Then you would be able to use 'cd school' to get to your school folder from any working directory!

Website updated!

My professional webpage, http://www.berkeleychurchill.com, just got a facelift.  Let me know if you like it.  Or more importantly, let me know if you hate it, find a typo, or something does not work right.

Berkeley in kernel land - the conclusion

I should finish up my short-lived series of posts on the little operating system I was working on.  Eventually I discovered that I actually knew everything I needed to know to really build an operating system.  For the longest time it seemed like such an abstract task that I did not know how to do.

But after spending a few weeks working with x86 documentation and actually building a kernel, I realized it was something I could do.  Then the can of worms opened: now that I could build an operating system, what on earth would I build? I could build a macrokernel.  Or a microkernel.  Or an exokernel.  I could map to kernel into the top or bottom half of the memory.  And that is only the very beginning.  The possibilities were limitless, and I could have spent months just planning the operating system I wanted to build.

Because I started with the goal of learning how to build an operating system, I discovered that I had accomplished that goal.  All my system did was read files out of a fat filesystem and execute programs that concurrently printed As, Bs and Cs across my screen.  But my goal was never to build a complete operating system.

So having my goal accomplished, I decided that I did not want to spend the rest of my life building a perfect kernel.  And that's when I stopped.

Fixing a file's "kind" on Mac OS X

Yesterday I had an annoying problem where I was emailed a file and then had to open it using a closed-source program on Mac OS X.  The issue was that the program only wanted to open a file of a certain "kind"; even though all the data was in the file and the file was in-tact the program would refuse to open it. 

Searching on google, there are several utilities that one can install to fix this metadata problem.  However, I was not the administrator of this computer as it was in a lab setting.  Here was a nifty solution.

I had already created several files from this program (Groups and Graphs).  Using a hexeditor I verified that the 'kind' information is definitely stored in the filesystem, and was not based on the contents of the files at all.  If I couldn't change the metadata, I figured I could copy the contents (but not the entire file object) of the file into a file that did have correct metadata.  Here's how this worked.  I had a file, old-good-file, of the correct type that opened.  My new file that wouldn't open was called new-bad-file.

Then in a shell I ran,

cp old-good-file new-good-file
dd if=new-bad-file of=new-good-file

 This way the contents of new-bad-file were moved to new-good-file without changing the metadata of new-good-file.  new-good-file inherited its metadata from old-good-file.  Now new-good-file works perfectly!

Berkeley in Kernel Land (part 2)

I've done a lot of work this week! Who needs classes when you can write operating systems?!?! This week I have,

• Written code to run flat binaries from a filesystem
• Got a few basic syscalls working (write() and exit() so far).  write() only outputs to stdout, which is currently always directly to the screen.
• Made my first live-cds and booted real computers!
• Written a scheduler!!

The scheduler is really the biggest step forward here.  I still have some kinks to work out; my first design worked robustly but lacked the flexibility for me to fully implement sleep, waits, etc.  To improve it I mostly needed to reorganize code -- but after refactoring, it lost some stability.  It seems to work find in the bochs vm and on real hardware but the first sign of trouble was qemu-kvm having problems.  After disabling kvm, qemu did okay for a while.  Now qemu is having issues.  I think I need to go back through my subversion history and figure out when everything went wrong...

Although it's really temping to jump ahead, I want to get this scheduler working cleanly on each of my test platforms before I continue.  I'm really excited to implement VFS and many more syscalls to get newlib working -- but it looks like that will have to hold for a while.

Berkeley in Kernel Land (part 1)

Last Wednesday I decided that I wanted to learn more about operating systems. Sure, I've taken UCSB's operating systems class (and done well in it), but operating systems are so huge and daunting that I felt more was necessary.

So I decided to write one. The goal is to build an operating system that works at some basic level; right now I don't have any further objectives. Ideas have crossed my mind, such as building a system that has a little extra support for stage lighting technology (like DMX-512) among other things. Stage lighting is another hobby of mine.

The OS Dev wiki has been an invaluable source of information! It provides the guidance needed for an experienced programmer with a computer science background to start working on an OS.

So far I've done the following:

• Setup GRUB as a bootloader
• a simple page allocator
• Wrote drivers for vga output, keyboard input, the PIT (programmable timer), the serial port and a dummy ramdisk (which disguises a memory mapped image as a hard drive).
• Wrote filesystem support for FAT-32
• Just last night I built a simple shell that you can use to browse a FAT-32 filesystem

Here are some next steps going forward:

• I need a virtual file system to abstract-away the details of FAT-32
• Code to execute user space programs (for now, just flat binaries -- but in the future I'll use ELF).
  
• A scheduler


• a fancier memory allocator


• Port a C library (perhaps newlib?)


• Port GNU core utils


• More drivers: including ACPI, cdrom, networking, and hard disk


• More filesystems: FAT-16 (easy), ext2/3/4 (harder), others?

Long term, I'm thinking about using modules to replace most drivers and filesystems. Unlike modern linux distributions, my goal is to minimize dynamic module loading and compile as little as possible into the kernel. Hopefully extra needed modules can be loaded from a static list on boot. I'd like to stick to a system that's quite a bit meaner-and-leaner than linux, even if it lacks many capabilities.

Right now GUI is off the radar, but it might be a possibility if I really have time...

That's all for now, but I'm going to try to post updates weekly. By the way, I'm still working on a name for this thing...

Under Attack!!

My roommate had a server running in our living room for a few months now.  I became skeptical about how much it was actually being used, so I decided to check out the /var/log/auth.log file and count logins.  After filtering out all the cron jobs, I immediately noticed a few suspicious lines:

    May  2 18:56:29 Mc-server sshd[27075]: Invalid user angela from 58.30.236.115
    May  2 18:56:29 Mc-server sshd[27075]: pam_unix(sshd:auth): check pass; user unknown
    May  2 18:56:29 Mc-server sshd[27075]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.30.236.115
    May  2 18:56:30 Mc-server sshd[27075]: Failed password for invalid user angela from 58.30.236.115 port 58943 ssh2

Ok, um, I don't know of any Angelas who live in my house.  Sketchy.  I ran GeoIP on the IP address, and guess what?  It's Chinese!  Unless my roommate has more international connections than I suspected, this is quite unusual.


    grep /var/log/auth.log 58.30.236.115 | wc

       3807   52210  440164


Huh.  Now we're talking about a small password cracking attempt.  It turns out that we actually were attacked four times within a 24-hour period.  Our logs only date back two days (they were cluttered with CRON entries), so we really don't know what happened before that.


Attack 1
06:16:01 to 06:34:42
From 119.161.145.206
20 attacks against 'root'
212 attacks against other accounts

Attack 2
09:09:26 to 09:10:25
From 125.208.5.78
11 attacks against 'root'
4 attacks against other accounts

Attack 3
17:10:09 to 18:56:30
From 58.30.236.115
576 attacks against 'root'
900 attacks against other accounts

Attack 4
22:49:55
from 125.88.105.43
A single attack without a valid authentication string.  Perhaps trying to exploit some old vulnerability?


SUMMARY:
* A total of 1703 attempted logins
* 607 attempts made against 'root'
* 166 attempts made against 'admin'
* The other 930 attacks were made against 531 usernames that appear to have been chosen from English dictionaries
* They never correctly guessed an active username on the system (other than root and some common system names).

Just for good measure, in the end we brought the system offline and checked for any malware/rootkits.  To no surprise, nothing suspicious was found.

So why did this happen to us?  When the SSH server was setup it was put on the default port 22.  This is just asking for trouble.  Never ever do this.  While we do not believe the system was ever compromised its just an invitation for problems.

What else do you learn from this?  (#1) By default there is no notification system to warn you of suspicious activity.  A cron job would be an easy fix.  (#2) Never give default system accounts (especially "root") SSH access.  This is the biggest target.  (#3) Don't use port 22, or other common service ports, if practical.



Of course, there are far more things you can do to protect your SSH servers. These suggestions really only graze the surface and should get you started on a better configuration for your servers.