I don't want to duplicate the chown man page, or LDP User Guide, but:

Every file has a single owner (UID) and group owner (GID) and access permission bits (-rwx rwx rwx), arranged as user-group-other.

Every user has a UID number, as specified in /etc/passwd, a primary group number (specified in /etc/passwd) and a list of extra groups (see /etc/group). /etc/group and /etc/passwd convert from numbers to names.

Actually UNIX and Linux (Linux is not UNIX, that is a trade mark), work internally using numbers. When you login, your username is used to select your UID, and your main login shell process starts running as that UID.

Your process is given and keeps your UID. Every sub-process you start has that UID. Ditto for GID, and list of secondary groups. It is the kernel that enforces this scheme, by checking the permissions every time you open a file, or make a special system call.

If the process accessing the file has the same UID as the file, then the user rwx (read-write-execute) bits are tried FIRST.

If the process accessing the file has GID (or can get it from its login owners group list), the group rwx bits apply.

If neither of those worked, the accessing process is not the files user, or a member of that group, the other rwx bits apply.

The Three lots of 3 bits are usually written in octal (the one place I can stand octal), so an executable script is usually 775 or 755, depending on whether the group is allowed to write the file, or just read it. Plain data files are ususlly 664, 644, 640 or 600. Files you really don't want to accidently mess with are ususally 444 or 400.

Other bits are also possible, but less often used. See man chmod(1) chmod(2) stat(2).

Pay special attention to system files that contain passwords to other systems, eg your dial-in ISP.dip script contains your password to access the ISP's machine. If someone gets that, they can login to your ISP as you, take your email, send email as you, and you might never know.

The best cure for that, is for the ISP to log the calling phone number of every caller, and send you a list every week by email. That would also give a vital clue to tracing down whoever is doing the illegal access. I don't think many ISP's offer this service (yet). Ask.

Every device also has permissions similar to files. These are applied when you OPEN the device (eg /dev/modem).

Being actual code, the device driver is able to find out more information about you, not just that you opened the device.

It can find out your UID, GID and PID. From the PID, a lot more can be found, such as your login terminal. That's how /dev/tty works.

TCP/IP comes with a collection of virtual devices, called eth0, ppp0, sl0, lo. Although these have similar names they are NOT the same as /dev/eth0. You will "always" need root permission to access them.

When you make a system call, the kernel code can enquire as to your UID (etc). In fact it is the open() call that checks your permissions when opening a file.

Most system calls, don't do any checking, which is faster, because they offer the service to anyone. EG getting the system clock is a basic right of a program running on Linux.

However, setting the system clock, is something that only root should be able to do, so the syscall checks and enforces the permissions.

Noe that the permissions on the executable files have to be OK, then again for the system call. This is why the "slattach" program, which calls the "slattach()" function fails for non root users, even though they have permission to run the program.

TCP/IP reconfiguration, is a "root controlled" thing, because other users might create a spoofing identity that leaves your system security in shreds.

If your system has it, use the adduser command, and follow the prompts. It edits /etc/passwd for you. See also /etc/group, and /etc/shadow if your system uses it.

Your login name is something daft, but unique, like gps (only different).

Your Full name will be posted in all Email headings, and such. It is a field in /etc/passwd.

Your GID is the default group (files you create will be group-owned by this GID).

You can be in any number of groups. When attempting to open a file, the kernel will cycle through the group list (NFS also?). This is done later by editing /etc/group. Your primary group is the one used to tag new files that you create.

You can use two commands to change the ownership of any file, these are chown and chgrp. chmod changes the mode of the file (eg read-only for you, the group, others).

chown root	/var/log/messages
chgrp root	/var/log/messages # group by same name !coinicdence
chmod 600	/var/log/messages # ISP password often logged here

Actually it is possible for several users to share the same UID, but have different login names, passwords and shells. You don't normally want this.

Your $HOME dir is /home/gps. You can use a symbolic link to move it to another disk.

Your Shell is /bin/bash. Much like SVR4 /bin/sh (Bourne Again Shell), not at all like BSD /bin/csh. bash has command line editing and is a good standard shell.

Your Password is YOUR password. Root can change it with passwd gps, so can you, but you will have to prove you know the old one.

Is that Correct Y/N ? If you say N, you'll have to type it all again.

If you don't have the adduser command, you will have to edit the files manually. Other distibutions (such as Linux Universe and Linux-FT) have other utilities to help you with this, eg xadmin.

All that information is put in /etc/passwd, for all to read.

The password is encoded, only the correct password or a coincidence will generate the same encrypted checksum that is in /etc/passwd.

If this is a no-login user, such as lpd or nobody, edit /etc/passwd and put in a key that is not a legal crypted key. EG '*' or 'no-login'

The primary group is set here, files you create will have this GID.

The shell can be /bin/sh for a normal login, /bin/sh for a BBS login, or /bin/BBS-BINARY or even /bin/BBS-SCRIPT. If it is is blank, it defaults to /bin/sh.

A /bin/BBS-SCRIPT script must have #!/bin/sh (or other) as it's first line, otherwise the kernel won't be able to make sense of the script text. It can be any executable, such as /usr/bin/perl or /usr/bin/wish, not just /bin/sh.

The name of the script will be put into $SHELL as a sign of preference. Secure applications would check SHELL with /etc/passwd. You may have to edit /etc/shells, to use them as your login shell, or derived binary.

This isn't used by the default Slackware, but you can switch to using it by replacing and re-configuring some system components. There is probably a FAQ somewhere.

The point is to remove the password-key from /etc/passwd, and put it in /etc/shadow, which only root can read. This stops hackers walking off with your list of crypted-password-keys, and finding the password by brute-force testing every combination of letters (or known previous passwords).

/etc/shadow also adds password age control parameters. ie you can automatically make users change passwords after 90 days.

This lists the NAMES of the groups (the kernel uses UID numbers internally), and lists group members (if not already in that group from /etc/passwd).

Add yourself to the any number of secondary groups, as:

floppy::11:root,gps

To be able to re-format disks, and to mount them (unless the user tag is used in /etc/fstab), you need rw access to /dev/fd0. This should already be done as the device is 660 UID=root, GID=floppy.

ls -l /dev/fd0* | less
chgrp floppy /dev/fd0*

/dev/fd0 does an autodetect floppy format (sectors per track etc), so that pre-formatted diskettes work every time (almost).

If the disk has not already been formatted, the auto-detect on the /dev/fd0 device will fail, and the driver won't know how many sectors/tracks you want. It says: ioctl(FDGETPRM): No such devicea

Naming /dev/fd0h1440 goes past the autodetect. /etc/fdprm also has an effect (I once formatted a 1440 as a 1200, but can't remmeber how or why).

With an old release (kernel / distribution / bad-disk?) I had the following mystery. I presume it was a bug, as it now works.

Single-sided, 0 tracks, 0 sec/track. Total capacity 0 kB.

The CMOS settings also have an effect, make sure that A: is defined as a 3.5" type floppy (if it is). Otherwise any boot disk you create will be of the wrong format, and will only work at that setting!

Is related to /dev/fd*, the man page is setfdprm. Hopefully you don't need to know about it.

These are used to change the permissions of files, devices etc. It isn't possible to change a symbolic link, you change it's target!

chgrp floppy /dev/cdrom
chmod 644 *.tcl
chown -R gps /home/gps/new-package

A symbolic link is a confusing chameleon. In a trick of mirrors, it is both the mirror and the reflection. It is a ponter to a file, directory or device. Any commands you run on that symb-link, effect the file it points to, except the commands that apply to the symb-link itself!

EG If /home/gps is really a symb-link to /hdc2/gps, then cd /home/gps puts you in the /hdc2 directory. However rm /home/gps only removes the link, not the directory! ls -l /home/gps lists the link, whereas ls -l /home/gps/. lists the directory!

The ln -s command appears to be backwards, until you realise it follows the ln, cp and mv commands. Ie bring some thing that exists to something new.

ln -s doesn't actually check whether it really exists, which does make sense. EG deleting the real file doesn't remove the link, so creating a link when there is no real file is also allowed.

ln -s /home/gps/.Xdefaults /home/root
cd /usr/src/linux ; ln -s linux-1.99.3 linux
ln -s /tmp/pkgs_ftp/package-0.55/lib /usr/lib/package
ln -s /tmp/pkgs_ftp/package-0.55/lib /usr/src/package
# where 'package' is some name 

Even with these problems, I like symb-links. Note that most links will actually fit within the links i-node, so use up much less disk space (excpet for UMSDOS, where they are kept as files, not entries in the table file).