|
|
|
|
Help, I've FallenCopyright © 1999 Gary Kline, David Leonard, and Dirk Myers
Welcome to the June issue!Here are another five of the more commonly-asked questions to help those new to Berkeley Unix.
Q: Why not use root as my general-use account? I've always used godlike power with DOS/Windows. I'm careful. What's the problem?A:From its very conception, Unix was designed to be a multi-user system. Much of the robustness and stability of Unix come from the fact that concurrent user processes are insulated against each other. You lose a lot of that by running as root all the time. This is how Unix was conceived and designed to be used---as a multi-user system. Unix prevents you from doing irreparable damage to the entire system when running from your own account. When a process is running with the privileges of root a lot of these security and sanity checks are bypassed. Even Windows95/98 (a single-user system where everything runs as root) has unbypassable safeguards that make it somewhat difficult to inadvertently ruin your system. Unix by design allows root to do just about anything. A concentrated point of control over the system is one of the appealing things about Unix. Although, it means that mistakes as root can have dire consequences. As root you can ruin your system, or critical parts of it, by cd'ing to the wrong directory tree and doing a rm -rf *. You can su to root in one window and, forgetting to move the X cursor to another xterm--or merely forgetting which directory your are in, commit irreparable harm. Everyone who has used a Unix system for very long has made these kinds of mistakes, totally inadvertently. # cd /space/downloads # ftp ... (download new files including a kernel) write: No space left on device # cd /(running out of space on /space) (check some files lazily left in /) # ls ... You have new mail # mail (forget that had cd'd to /) # mv * /tmp (Thinking still in /space/downloads) (just moved all directories into /tmp - eek!) # ls ls: command not found # ^D (really tired) /dev/console: No such file or directory (stunned silence) These scenarios are contrived, but these and less obvious things have happened. Even if you are mindful and extremely careful 99.9% of the time, it is that last tenth of a percent that will get you. Given such potential for harm, it's a good system administrator's rule of thumb that routine tasks such as downloading and juggling user files and shouldn't be done as root. Editing a file, sending mail, compiling a program, creating files, directories, subdirectories--and removing them--these things and much more should be done using your own, personal login account. Use root solely for system administration, and use a different account for everything else. Sudo is a program that stops you from even having to login as root.
After a few months of using Unix correctly you'll shudder at
the thought of using root unnecessarily. It's part of moving into a new
and considerably more powerful paradigm.
Q: How can I remove a bizarre, irremovable file from a directory? I've tried every way of using /bin/rm and nothing works."A: In some rare cases a strangely-named file will show itself in your directory and appear to be un-removable with the rm command. Here is will the use of ls -li and find with its -inum [inode] primary does the job.Let's say that ls -l shows your irremovable as -rw------- 1 smith smith 0 Feb 1 09:22 ?*?*P Type: ls -lito get the index node, or inode. 153805 -rw------- 1 smith smith 0 Feb 1 09:22 ?*?^P The inode for this file is 153805. Use find -inum [inode] to make sure that the file is correctly identified. % find -inum 153805 -print ./?*?*PHere, we see that it is. Then used the -exec functionality to do the remove. .
% find . -inum 153805 -print -exec /bin/rm {} \;
Note that if this strangely named file were not of
zero-length, it might contain accidentally misplaced and
wanted data. Then you might want to determine what kind of
data the file contains and move the file to some temporary
directory for further investigation, for example:
% find . -inum 153805 -print -exec /bin/mv {} unknown.file \;
Will rename the file to unknown.file, so you can easily inspect it.
Another way to remove strangely-named files is to use "ls -q" or "cat -v" to show the special characters, and then use shell's globbing mechanism to delete the file. $ ls -????*'? $ ls | cat -v -^B^C?^?*' $ rm ./-'^B'* -- achieved by typing control-V control-B $ lsthe argument given to rm is a judicious selection of glob wildcards (*'s) and sufficient control characters to uniquely identify the file. The leading "./" is useful when the file begins with a hyphen. These binary name files are caused by:
If you discover that you have two files of the same name, one of the files probably has a bizarre (and unprintable) character in its name. Most probably, this unprintable character is a backspace. For example:
$ ls
filename filename
$ ls -q
filename fl?ilename
$ ls | cat -v
filename
fl^Hilename
Q: Can you suggest some general shell aliases for a new user? I use bash or ksh.A: It may seem strange to people from a DOS background to find the kinds of abbreviations that he finds in Unix, but a few words of explanation may be of some interest. Unix was created some 30 years ago when communication with the main computer was typically via a Teletype which was slow, noisy, and whose typewritten I/O was printed on a roll of paper. Because of this slowness, commands like copy, ren, and list were abbreviated. To catenate a file onto the paper, "cat" became the chosen abbreviation. You may find it "friendlier" or "familiar" to alias
copy() {/bin/cp $* }
dir() {/bin/ls $* }
ren() {/bin/mv $* }
but eventually you are likely to go with the flow of the Unix paradigm.
The Unix cp, mv, and ls are considerably more
powerful than their old DOS counterparts.
What follows are just a few of the most popular aliases. First, for the list command ls:
ll(){ /bin/ls -l $* }
lt(){ /bin/ls -lt $* }
l() { /bin/ls -ls -F $* }
Next, for the cd or chdir command: c() {cd $* } Finally, to determine which directory you are working in now, pwd becomes simply d() {pwd } As with most things in the Unix world, everyone has his own favorites and biases, so use these suggestions only as your first-cut guidelines.
Q: How do I go to single-user mode from multi?su - to root and type# shutdown nowThe shutdown command will lower your system into single-user mode at time = now; i.e., immediately. To give yourself or any other users time to logout comfortably, use the format +minutes. You can also add a message, which will be displayed to everyone logged into the system with increasing frequency as the shutdown time approaches: # shutdown +10 "system is going down for preventative maintenance. Please logout"This command will give everyone (including yourself) 10 minutes to complete all normal user activities before BSD goes into single-user mode. Q5: How do I block people from logging in via telnet and still allow ftp?A: Comment out this line in /etc/inetd.conf:telnet stream tcp nowait root /usr/libexec/telnetd telnetdThis will turn off telnet service--your system will refuse all telnet connections. If you wish to allow some users to telnet in and deny selected others, use the /etc/login.access file. If you wish to refuse user "smith" from logging in (by any means), in /etc/login.access, append the line -:smith:ALL Other users may be added after "smith". -:smith jones joe sam: ALLfor example. The login.access control table syntax is fairly straightforward and will let to choose whom to allow or deny easily. Another way that you can refuse logins is by changing a user's default shell to /sbin/nologin. As root, 'chpass' to change the user's shell: #chpass onlyftpMore depth on the chpass utility in our December, 1998 column. (see Dæmonnews Answerman December 1998 issue) To do this, though, you also need to add '/sbin/nologin' to /etc/shells, as the ftp daemon will refuse access to any user with a shell that does not appear in /etc/shells. The tcp_wrappers port in the security ports' directory of FreeBSD, you will be able to monitor and filter requests for network services like ftp, telnet, and more. OpenBSD has 'tcp wrappers' in the base dist. For access control on both telnet and ftp, and to be able to log attempts at using those services, in inetd.conf:
/etc/inetd.conf: ftp stream tcp nowait root /usr/libexec/tcpd ftpd -US telnet stream tcp nowait root /usr/libexec/tcpd telnetd -k Create the files /etc/hosts.allow and /etc/hosts.deny. For some specific examples, let's say that you want to allow ftp access to everybody except users joe, john, and sam. In hosts.allow you would have:
/etc/hosts.allow:
# allow ftp access
ftpd: ALL EXCEPT joe@ALL, john@ALL, sam@ALL
And if you wanted to deny telnet to everyone except erik, in
hosts.deny you would put:
/etc/hosts.deny:
# default is to deny all services unless explicitly allowed
telnet: ALL EXCEPT erik@ALL
Tip of the month:Back doors and backup login account may prove valuable if your standard root or user account becomes unusable due to some disaster. Fixing things by booting in single-user mode may not always be the better way. If your name is John A Smith and you normal account is, say, "smith", creating a backdoor account, "jas" with an identical environment and little else is a good idea. If you have your "smith" account in the `wheel' group in /etc/groups, and in other useful groups, remember to add your backdoor account also. For your root backup, consider the "toor" account. toor may be useful for any number of reasons including simply maintaining a different working environment. toor traditionally uses /bin/sh rather than /bin/csh, so you may want to include things in your /root/.profile to make life a bit more comfortable within toor; but, of course, not that comfortable. Because toor can be a security risk, be sure to give it a strong password.
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.orgDavid Leonard, david.leonard@csee.uq.edu.auDirk Myers, dirkm@buster.dhis.org
|
||