justlinux.com
Mon, 23-Nov-2009 09:35:41 GMT
internet.com
Forum: Registered Users: 73495, Online: 279
nhfs Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home Home

Help File Library: File Permissions NHF


Written By: Sterling

One of the things that makes Unix different from Windows are file ownership and permissions.

File Ownership:

All files are on a Unix system are owned by a user and a group. Users own files they create, and root can change the ownership of files through the "chown" utility. A file's group is set to the primary group of the user that creates it initially. Since users can belong to more than one group (and often do), a user can change the group of any file they own with the "chgrp" utility to any group they belong to. You can use the "groups" utility to list what groups you (and others) belong to.

Commands:

chown [user] [file]
chgrp [group] [file]
groups [user]

File Permissions:

File permissions control who can do what to a file. They're divided into four sections. Extended permissions are delt with in another part of this NHF. User permissions control what the user who owns a file can do to it. Group permissions control what members of a group that owns a file can do to it. World or other permissions control what everyone else can do to the file.

Each section is represented internally as three bits, which gives three on/off fields for each. For user, group, and other, the fields are:

read - The user/group can read the contents of the file. For directories, this means the user/group can list its contents.

write - The user/group can write to the file, changing the data in it however they want. For directories, it gives permission to create/remove files, so you can't actually DELETE a file unless you've got write perms to the directory its in.

execute - The program can be run by the user/group. For directories, it means you can cd into the directory.

Representing File Permissions:

There are two ways to represent file permissions: symbolic and numeric

Symbolic Representation:

File modes are represented using letters and symbols familiar to humans. These are fairly easy to understand, and are well-documented in the info pages, so point your favorite info viewer (I like pinfo, personally) at "info chmod", follow the "File Permissions" then the "Symbolic Modes" links, and then read.

(Author's Note - If someone feels like writing up a good Symbolic Representations bit, E-Mail it to me and I'll throw it in here. The info pages are quite good, though.)

Numeric Representation:

This is a bit more confusing, so I'll go into more detail here.

As each field of the file's permissions is three bits, it can be represented as a series of octal (base 8) numbers. The maximum base-10 value three bits can have is seven, which is the maximum value for a single digit in base 8. Read perms (bit 3) are represented by a 4. Write perms (bit 2) are represented by a 2. Execute perms (bit 1) are represented by a 1. To specify multiple permissions, just add their values together. For example, to specify read and write perms, you'd use a 6. To specify all of read, write, and execute, you'd use a 7. To specify none, use a 0.

Now, to actually specify these, you use four digits. The first specifies extended file perms (covered below), and is almost always 0. The second specifies user permissions, the third group permissions, and the fourth world permissions.

So to specify user read, write and execute, group read and execute, and world read, you'd use:
0754

Commands:
chmod [permissions specifier] [file]

Extended File Permissions:

suid and sgid bits are fairly simple - although it may not seem so at first sight. They only matter for executable programs and directories.

Whenever a program is run, the permissions of the task it creates are set to the user and primary group of the user that runs it. What it can do is then limited by that. There are a bunch of rules about what it can then change its group and user permissions to, but they don't matter for the purposes of this discussion. Any good book/reference on Linux programming should provide more information.

Sometimes, however, you want a program that ordinary users run to be able to do root-y things. Or you want something to always run as a certant user or group (for whatever reason). That's where the suid and sgid bits come in. If the suid bit is set on a program, that program will always run with the permissions of the user that owns it. The suid bit has no effect whatsoever on directories. Its the number 4 when using numeric file permissions.

The sgid bit means it always runs with the permission of the group that owns it. It doesn't always have an effect for directories, but on some systems, it means that any files created in the directory are owned by the group that owns the directory, no matter what group the user created them as. The sgid bit is represented by 2 when using numeric file permissions.

Both bits can, however, cause big huge gaping security holes if misapplied. So be extremely careful when using them - and never use them if there's a better way.

There are supposed to be more finely-grained security levels that are being introduced at some point soon, but I haven't read anything about them for a long time. If anyone finds any information on this, E-Mail it to me and I'll add some links.

References:

info chmod
info groups
info chgrp

internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers
internet.commerce
Be a Commerce Partner











internet.commediabistro.comJusttechjobs.comGraphics.com

Search:

WebMediaBrands Corporate Info

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs