So, I'm looking at the permissions of a directory:
I see:
Owner
Group
World
I have two users, spot and root. Root can run anything right? What if root runs something that is owned by spot? In this case will the application run with the permissions of root or spot?
How is it implemented? I recall reading some configuration files that gives user root, root like permissions. I can't recall where they are located though.
How do linux Permissions Work?
Re: How do linux Permissions Work?
It will run with root's permissionss243a wrote: What if root runs something that is owned by spot? In this case will the application run with the permissions of root or spot?
Re: How do linux Permissions Work?
inodes store file, directories etc permission data http://en.wikipedia.org/wiki/Inodes243a wrote:How is it implemented? I recall reading some configuration files that gives user root, root like permissions. I can't recall where they are located though.
I suspect the file you're referring to for permissions is /etc/passwd
Standard permissions refer to one's ability to access the file.
So, if you have execute permissions for a file, you can run it.
The *process* will belong to you, if it is a regular file.
However, read-write-execute permissions for "user", "group", and "other" only occupies 9 bits of the 32 bits available for storing the file mode.
The other bits include:
-setuid: if you run a setuid file, the process will belong to the owner of the file
-setgid: if you run a setgid file, the user owning the process is unchanged but the group owning the process is the group owning the file
-sticky: when set on a directory, only owners of files in the directory can delete them (by default, anyone with write access to the directory can delete any of its contents)
These are bits 04000, 02000, and 01000 respecttively.
Besides those, there are a lot of bits to do with "special files", describing whether the file is a block device, char device, socket, symbolic link, named pipe (FIFO), or directory. has more of the technical details, if you're interested.
From the kernel's perspective, a "user" is identified by a number, their "user id" (uid).
On most unix-like systems, these are mapped to user names via entries in /etc/passwd; generally, "root" is uid 0.
A similar situation applies to groups, though the file mapping group ids to group names is /etc/group.
root is able to do what it can do because it's uid 0, rather than because of user name; the behavior is mostly set in the kernel.
Other users are generally able to do a subset of what root can do under certain conditions:
-via sudo (configured via /etc/sudoers) or setuid binaries
-for devices, if the device has permissions giving them access
-if files have filesystem capabilities enabled (a topic I'm barely aware of)
So, if you have execute permissions for a file, you can run it.
The *process* will belong to you, if it is a regular file.
However, read-write-execute permissions for "user", "group", and "other" only occupies 9 bits of the 32 bits available for storing the file mode.
The other bits include:
-setuid: if you run a setuid file, the process will belong to the owner of the file
-setgid: if you run a setgid file, the user owning the process is unchanged but the group owning the process is the group owning the file
-sticky: when set on a directory, only owners of files in the directory can delete them (by default, anyone with write access to the directory can delete any of its contents)
These are bits 04000, 02000, and 01000 respecttively.
Besides those, there are a lot of bits to do with "special files", describing whether the file is a block device, char device, socket, symbolic link, named pipe (FIFO), or directory.
Code: Select all
man 2 statFrom the kernel's perspective, a "user" is identified by a number, their "user id" (uid).
On most unix-like systems, these are mapped to user names via entries in /etc/passwd; generally, "root" is uid 0.
A similar situation applies to groups, though the file mapping group ids to group names is /etc/group.
root is able to do what it can do because it's uid 0, rather than because of user name; the behavior is mostly set in the kernel.
Other users are generally able to do a subset of what root can do under certain conditions:
-via sudo (configured via /etc/sudoers) or setuid binaries
-for devices, if the device has permissions giving them access
-if files have filesystem capabilities enabled (a topic I'm barely aware of)