Monthly Columns
Contents
Editorial
Corporate BSD
BSD News
Darby Daemon
The Answer Man
Newbie's Corner
Dæmon's Advocate

Help, I've Fallen

Copyright © 1999 Gary Kline, David Leonard, and Dirk Myers

Now that April's here... we're heading into springtime in the Northern hemisphere and into autumn South of the Line. Time for a minor break from the usual column. We have seven of the most commonly asked questions and answers.

As more people check out this column these questions will not be asked so frequently. Those new BSD users who ask any of the questions covered in this column can be pointed to the appropriate URL. This fits the way that people have been learning Unix for decades: people helping one another.

List of Topics





Q: When I was trying to upgrade my system, I tried 



# /bin/rm -rf /usr/obj

to clean my /usr/obj directory of old object files, but I received 'Permission denied' messages for several files. I was running this command as root. Why don't I have permission to delete these files? Is there some way I can get rid of them?


A: The files you are trying to delete are probably protected by the immutable flag ('schg'). The immutable flag prevents anyone (even root) from deleting or modifying the file. This can improve security since it is possible to put your machine into a 'secure' mode where immutable flags cannot be turned off. Many systems default to running in this mode.

Try: 


# chflags -R noschg /usr/obj
to turn off any 'schg' flags, and then try removing the files again: 

# /bin/rm -rf /usr/obj
You may have a personal file that you do not wish to lose by accidental removal. As root, set the file to unchangeable mode with 

# chflags schg personal.addresses
You can see if a file is immutable by using 'ls -lo'. 


% ls -lo personal.addresses

-rw-r--r--  1 root   wheel  schg    1598 Mar 27 14:44 personal.addresses
If you received a 'Permission denied' message when attempting to remove the 'schg' flag, you're running in secure mode, and you'll need to shutdown to single-user to clear the flag.

There are other flags besides 'schg' which you can use to protect files. The ones I've found most useful are:

uchg User immutable flag. This is a flag similar to schg, but which can be set and/or removed by a user.
sappend System append-only flag. Allows additions to the file, but does not allow removal or deletion. This is a useful flag to set for things like system logs. Can only be set and/or removed by root.
uappend User append-only flag. Allows additions to the file, but does not allow removal or deletion. Can be set and/or removed by a user.
% man chflags will give you more details about schg and other options.


Q: How does the BSD password system work?


A: *BSD uses a "shadow password" system. There is an /etc/passwd file, as UNIX systems have always had, but it doesn't contain the actual passwords. Those are kept securely in /etc/master.passwd and/or in a hashed database /etc/spwd.db.

You can change your password, and associated data yourself (see Dæmonnews Answerman December 1998 issue)

A quick history and explanation about password encryption and storage:

When you choose a password (say "amanda1"), Unix doesn't actually store that word anywhere. Doing so would mean that if someone else got root access, they could just read your password straight off and probably have instant access to your accounts on other computers.

Instead, Unix stores an irreversibly encrypted (mangled) version of your password. (e.g. "amanda1" becomes "xxR8JnJGJevfs").

Hang on, you might ask. If its irreversible, how can the system know that my password is right the next time I go to type it in?

Well, quite cleverly, the system just takes what you typed, applies the *same* one-way encryption process, and compares *that* with what it has stored. If they match, then you must have typed the same thing! (You have to be incredibly (un)lucky to find two passwords that encrypt to the same thing.)

Traditionally, these encrypted passwords were stored in /etc/passwd and made public. Not only did this file allow other programs to perform their own authentication, but at the same time it let them know what usernames were valid in the system, plus it contained other details, like your full name and your home directory. Because of the one-way nature of the encryption function it was thought to be safe for public display.

Unfortunately, as computers got faster, it was possible for someone to just pick out one of these encrypted passwords, and feed it into a program that tested it against *every* possible typed password. e.g. It might first try "a", "b" ... "z" and then "aa", "ab"... and so on. This is called a `brute force' attack, or `exhaustively searching the key space' and is popular because:

  • the crypt function is fast, and
  • people don't often type very long passwords.

A friend of one of the authors, once claimed that it took his 486 PC only 4 days to exhaustively crack a password!

Today, encrypted passwords are not held in the publicly-accessible /etc/passwd, but in a separate file called the `shadow password file'. Its name differs from system to system, but it is readable only by root.

Shadow passwording is not perfect (because of undiscovered flaws in root programs), so for extra security, stronger encryption functions are used. In particular, we choose encryption functions that take a lot of CPU time. This simply makes it more expensive for the bad guys.

For example, using Blowfish encryption, going from "amanda1" -> "$2a$12$eIAq8PR8sIUnJ1HaohxX2OVMYhP12bouPMdrzMLdfVSd5XcGfv7tS" takes 17.4 seconds, compared to traditional DES-56 where "amanda1" -> "xxR8JnJGJevfs" takes only 0.04 seconds (on a 120MHz Pentium).

Besides deciphering (brute force or otherwise), there are countless ways that your secret password can be intercepted between your fingers and the programs to which you type it. But that is beyond the scope of this article.

Future advances in authentication technologies may one day make the Unix password scheme obsolete (e.g. ssh). Until then, dynamic, open-source software like *BSD Unix is able to keep you abreast of ever-increasingly powerful hardware and clever encryption attacks.




Q: How can I change the login banner of my *BSD system?


A: The login banner is initialized in /etc/gettytab. For FreeBSD, OpenBSD and NetBSD, the line looks like: 

default:\
        :cb:ce:ck:lc:fd#1000:im=\r\nFreeBSD (%h) (%t)\r\n\r\n:sp#1200:

The actual contents will vary, depending on which *BSD you're running.

To customize your login, change the within to whatever you wish. For example: 


default:\
	:cb:ce:ck:lc:fd#1000:im=\r\nThe World's Best OS (%h)
(%t)\r\n\r\n:sp#1200:

To clear the screen you can issue as many "\r\n" pairs as you need. For example: 

default:\
       :cb:ce:ck:lc:fd#1000:im=\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n%h\r\n%t :sp#1200:



Q: Is there a way of rebooting my system (like ctl-alt-del) without having to stop and su to root?


A: Yes. Put your login name, say smith into the group operator; then you'll be able to run the shutdown command without having to su. You will have to be logged in, though. To add yourself to the operator group, edit the /etc/group file: 
operator:*:5:root,smith
Then, when you need to reboot, you can use the shutdown command with the -r (reboot) flag: 

$ shutdown -r now

Not quite as simple as the <ctl-alt-del> keystroke combo, but quite a bit easier than logging in as root. See the December, 1998 issue for a bit more On /etc/group



Q: How do I kill a print job and save dozens of sheets of paper without having to crash my system to stop the printer?


A: To kill a print job you must remove the job from your print queue. Use the line printer remove command, "lprm " .

To find the job-number, use the line printer queue (lpq) command to list the jobs in your print queue. 

%lpq

lp is ready and printing
Rank   Owner      Job  Files                                 Total Size
active kline      340  (standard input)                      19249 bytes

Then, simply remove it: 

% lprm 340

The job is gone (and you've saved all that paper!).




Q: When I set up my original filesystems I neglected to include /var, and now huge amounts of stuff are being dumped into my / root slice. Is there a way of using the free space in /usr for /var?


A: Yes. The simplest way to do this is by creating a symbolic link from /var to a directory under /usr (say, /usr/var).

A symbolic link is actually a tiny file that is interpreted by the operating system as an instruction that "what you're looking for isn't here, but you can find it over there." In other words, you tell your system to stop looking for /var on the root partition, and to use /usr/var instead.

(A hard link is not, strictly speaking, a link at all. Rather than telling the operating system to "go look over there", a hard link directly attaches another name to whatever it's linked to. To do this, though, the hard link has to live on the same filesystem as the original file -- so we can't use a hard link here.)

For more on how hard links and symbolic links actually work, see the following question: Why no free space after a huge rm -rf!?

First, move (mv) the contents of /var to the new directory. 

# mv /var /usr/var
Now that the contents of /var have been moved, it's time to tell the system where they've moved to. 
# ln -s /usr/var /var
The 'ln' command (link) makes a link from /var (the old location) to /usr/var (the new location). The -s flag tells 'ln' that it needs to make a symbolic link. (Mnemonic: the last argument to 'ln' is what is created.)

Note: This should all be done in single-user mode, otherwise daemons that are accessing the old /var may get confused and may not be able to recover on the next reboot.

Also, some periodic security software may start to complain because they don't expect a symbolic link at /var. Give /var its own partition the next time you buy a new disk!




Q: I deleted this big file, but my free disk space doesn't go up!


A: The file may not yet have been actually deleted. To understand what's going on here, we need to take you on a brief tour of the filesystem. Underneath, Unix filesystems are really a big jumbled collection of buckets of data. Each bucket of data (called an inode) holds the contents of one file, but the inode buckets aren't named -- they are simply numbered (inode numbers). You can give a name to a bucket by linking it into a directory. e.g., bucket #11833 might be `linked' to the name /etc/passwd. You can see the inode number of a file by using the -i flag with ls: 


  $ ls -i /etc/group /etc/passwd
  11712 /etc/group
  11833 /etc/passwd

Generally, there is no restriction on how many links an inode might have. This can be handy for saving disk space! Since programs can see what name they are called when they run, they can act differently. e.g., 'gzip' and 'gunzip' are just two names that refer to exactly the same inode--and therefore exactly the same program: 


  $ ls -i /usr/bin/gunzip /usr/bin/gzip
  38689 /usr/bin/gunzip
  38689 /usr/bin/gzip

Inodes keep track of how many outgoing links they have (the `link count'), and this is the number you see between the permissions and the owner when doing an ls -l. Here, we notice that the inode behind gzip actually has 3 links! 


  $ ls -il /usr/bin/gunzip /usr/bin/gzcat /usr/bin/gzip
  38689 -r-xr-xr-x  3 root  bin  106496 Mar  1 13:55 /usr/bin/gunzip
  38689 -r-xr-xr-x  3 root  bin  106496 Mar  1 13:55 /usr/bin/gzcat
  38689 -r-xr-xr-x  3 root  bin  106496 Mar  1 13:55 /usr/bin/gzip

Link counts are decreased by one whenever you rm a file. When the count gets to zero, the space consumed by the inode is marked as unused and the data is forgotten.

However, names are not the only things that consume links. Whenever you open a file for reading or writing or executing, the link count is silently increased by one. This means that you can rm a file (and hence unlink it from the directory tree) but if another program is using it, the system will not remove it from the disk. So, don't be surprised if you delete a big file, and your free disk space doesn't immediately increase: there is probably a process still using it. The link count will be decreased again when the process closes the file. (The system automatically closes a process's open files when the process exits or is killed.) The other possibility is that something else in the directory structure is linked to the same inode as the file you deleted -- to refer back to the example above, rm /usr/bin/gzcat would not free up any significant amount of disk space, because the only thing the system would remove would be the directory entry.

Because inode numbers are specific to a particular disk partition, and directories only keep inode numbers and names, it is impossible to link across filesystems. e.g. if you have two disks called /u0 and /u1, you can't link an inode in u0 to a filename under /u1 because the inode *number* you link to could be in use on both disks! The system couldn't know which one you meant, so instead, it assumes the inode is on the same disk as the directory in which it is mentioned.

Symbolic links

Symbolic links (a.k.a symlinks) do not involve inode numbers at all. Symlinks differ from real links (`hard' links), by storing a pathname instead of a number in the directory.

The file /etc/localtime is typically a symbolic link to a file in /usr/share. Because /usr/share is typically a shared disk, and /etc is on the computer's root disk, it is impossible to hard link their names to the same inode - so we use a symlink: 


  $ ls -l /etc/localtime
  lrwxr-xr-x  1 root  wheel  38 Jan  5 10:14 /etc/localtime ->
/usr/share/zoneinfo/Australia/Brisbane



Tip of the month:

The care and feeding of your computer systems.
aka "Preventative Maintenance."

There isn't much that the average computer can do to promote the longevity of its hardware. However, it isn't entirely a matter of planned obsolescence, although the hardware manufacturers would like you to discard your old hardware and buy new at least annually.

What can you do to keep your existing hardware running just a wee bit longer? Here are some routine suggestions.

  • Periodic cleaning. Whenever you upgrade something--say, when you pop in another 64MB of memory--invest an extra 15 minutes in gently vacuuming the dust out of your case.
  • Visually inspect the box for loose boards or plugs. Re-seat and reconnect things that need it.
  • Use cleaning kits to clean your QIC or 8mm or 4mm tape drives. Your tape back-up device was probably one of the most expensive components of your system, and investing the few dollars and minutes to keep these devices going is worthwhile.
  • Pay attention to the specs on your hardware and try to stay within them. Overclocking your CPU may not cause a problem, but drawing more power than your power supply is specified to provide, or refreshing your monitor faster than it can keep up with, is asking for trouble. 




disclaimer


This column takes on some of the more frequently pondered topics bi-monthly along with one or more advanced questions; these for each of the three flavors of BSD. We do our best with each question, but bear in mind that your results and opinions may vary. The authors of this column also tend to subscribe to the idea that it's not possible to protect you from the sharp instruments you'll find included with your *BSD system. While we try not to recommend anything inherently dangerous, it's up to you to use common sense in applying our recommendations.

Gary D. Kline, kline@tao.thought.org
David Leonard, david.leonard@csee.uq.edu.au
Dirk Myers dirkm@buster.dhis.org