POSIX permissions (Wikipedia)
$> ls -l drwxr-xr-- 5 siggi devs 4096 Jul 23 16:45 src lr-xr-xr-- 18 siggi devs 4096 Jul 23 17:03 libs-ext -> /usr/share/lib -rwxr--r-- 1 siggi devs 1378 Jul 25 01:45 build.sh -rw-r-w--- 1 siggi devs 187425 Jul 24 19:31 hello.js -rw-r----- 1 siggi devs 187425 Jul 24 19:31 readme.txt $>
we get some indications wether its a directory or a link,
rwx triads for owner, group and others,
number of elements,
the file owner and group.
furthermore the filesize and dateTime.
files :
r - read the file contents
folders :
w - write, delete the file and its contents
x - execute the file/script
r - read the directory content
this leaves some uncovered spots and ambiguities when You want to allow/disallow certain operations.
w - create, delete files in the directory
x - enter(cd) and execute files from the directory
for example: You want to allow group members to add files to Your folder, but not delte or overwrite existing files.
altering the current state/permissions of the folder itself or files within can only be performed by the file owner,
users with root/sudo privileges or by using setuid/setgid/stickyBit...
all in all it needs some tweaking and masking to get things done...
the owner of a file is defined by its uId,
ths group of a file is specified by its gId.
u - owner (set by uId or user name)
...expecting others to be anyone on the system. there is no differentiation between authenticated
system users or any network/server connected (maybe anonymous) user.
g - group (set by gId or group name)
o - others...
u - owner (set by/checked against - uId)
Allowing explicit public access to ceratin ressources has a lot of use cases:
from a simple http(s) server based off of a local file structure up to a distributed file- and operating system...
g - group (set by/checked against - gId)
o - other (authenticated system user, not in the specified group)
p - public (accessing via network/http(s), not authenticated)
Simply marking files as public... as in public library - accessible to anyone!
Or the other way - restricting access to p and giving access to o ensures the file/folder :
- can be accessed by any valid system users (independant of a specific group)
- but not by an unauthenticated public user.
The same principles are also reflected in the structure of the vfs :
- /users - containing the home folders for each user
- /groups - containing the group specific folders & their files
- /share - files & folders shared by all system users
- /public - public files & folders (by domain)
owner - by uId - the effective owner of the file
for collaborative environments files will be edited/changed by multipler users.
group - by gId - the assigned group of the file
creator - by uId - the creator of the file
especially in combination with file versioning, it it essential to know the creator.
current status: all files are owned by a group admin and the group members have write acces to them
by committing new version via git, svn, ...
the file owner remains as before, the storage of information about the creator is left to
the versioning software/service.
if the creator of a file is stored directly into the file information the following scenario
is possible:
// the group moderator creates a file and stores it. // default versioning is enabled... $> ls -l -rw------- 1 siggi devs siggi 1735 Jul 23 14:09 hello.js $> chmod g=rw ./hello.c // group members have writing access to the file -rw-rw---- 1 siggi devs siggi 1735 Jul 23 14:09 hello.js . . . // group member sven updates the file. $> cp ./myHello.js /.../repo/hello.js // the preexisting file/inode is unlinked from /repo // the new version is linked in its place, and the old inode is // linked to the backlog versioning field of the new one. -rw-rw---- 2 siggi devs sven 8527 Jul 27 04:58 hello.js $> versioning ./hello.js 2 versions found: * 1: sven 8527 Jul 27 04:58 hello.js - 0: siggi 1735 Jul 23 14:09 hello.jsalthough the above expample may be a bit simplified:
// the group moderator locks a file version // as [current]. extended versioning applies... $> versioning -makeCurrent ./hello.js -rw-rw---- 2 siggi devs sven 8527 Jul 27 04:58 hello.js . . . // group member felix sends an update. $> cp ./myNewHello.js /.../repo/hello.js // the new file is linked to the existing file // by placing it into the ahead versioning field(s). // the [current] version remains as before. -rw-rw---- 3 siggi devs sven 8527 Jul 27 04:58 hello.js $> versioning ./hello.js 3 versions found: ~ 2: felix 3538 Jul 28 11:59 hello.js // pending/ahead # 1: sven 8527 Jul 27 04:58 hello.js // current - 0: siggi 1735 Jul 23 14:09 hello.js . . . // after reviewing, the group moderator commits the update. $> versioning -commit -v=2 ./hello.js -rw-rw---- 3 siggi devs felix 3538 Jul 28 11:59 hello.jsagain, this might be a bit simplified for a better explanation...
r - reading permission
w - allow writing file/folder contents
m - allow modifying the file/folder
a - allow appending to file/folder
x! - extended execution/fileType flags
reading permission - should be self explanatory
anyway, reading permission includes the right to:
in case of folders:
Writing permission
If [w] is set, the specified permission group (ugop) may open the file
and write to it, delete or alter its content.
!! writing permission on regular files via open() is locking !!
in case of folders, [w] gives full access to the directory content,
allowing creation & deletion of folder entries.
Modifying permission
If [m] is set, the specified permission group may alter the
file/folder itself via rm, rmdir, unlink, mv, chmod, chown, chgroup, unmount.
Allowing [m] to (o) and (p) is not advised, but allowing [m] for group members
makes sense under certain circumstances...
Allowing modify does not include write access to the file/folder content !!
Appending permission
If [a] is set, the specified permission group (ugop) may alter the file/folder
content only by appending to it.
- in case of folders: new entries can be created
- in case of files or streams: [a] will not lock by default.
The filesystem will append-open() any regular file as if it is a stream, therfore
no seek() operations in append mode!
Multiple users may write simultaneously to the ressource in a FIFO manner. (e.g. log files)
As streams are multi-purpose, no automatic newlines or delimiters are applied. When appending to a stream,
consider appending meaningful and complete blocks, containing an appropriate delimiter.
The filesystem will ensure that the entire block of data is stored before writing the next one from the queue.
This field may contain various letters, including an optional [!]
Regular files are noted as [-],
setting [x] will behave as expected and make a file executable.
In case of special files, a corresponding letter will be placed in the first permission group for the file owner,
indicating the fileType and the input/output/content to expect - ([f] for folders, [s] for streams, [l] for links etc.)
As those special files cannot be made executable, their corresponding letters will not collide with the traditional [x].
propagating the fileTypes to group/other/public permissions will be done automatically and can be overridden.
by removing the [x] from the (o) and (p) group, it does as expected prohibit those users to execute the corresponding file.
removing the other letters for (op) is not neccessary as it is not a security issue.
if (o) have no reading rights they may see a file of type [s] but can not access its stream data.
anyway, if removing them explicitely those special files will be masked as if being
regular ones for (p)ublic visitors.
by setting a single [!] to a regular file, the filesystem marks the file as locked.
this means:
- the file was opened for exclusive write access from some user.
- if a different user has reading rights for this file, reading its content is possible but
may be incomplete (e.g. no longer the current version).
the filesystem will not prohibit reading access from a locked file or stream !
by adding a [!] to one of the above letters,
the corresponding special file is marked exclusive as follows:
all of the above are considered immutable!
- they cannot be copied or linked elsewhere
- they cannot be relocated or deleted
- they cannot be unmounted
- they cannot be altered via chown & chgroup
- chmod is restricted for (u) & (g)
propagation of the exclusive files/streams to group/other/public permissions will be done automatically and can be overridden.
in contrast to the simple flags they will not be removed. instead they will be marked as [!!]
this means effectively, the corresponding file will be completely hidden to the specific permission group.
!! non-exclusive files/streams may be also marked [!!] for (gop) !!
!! [!!] cannot be set for the file owner (u) !!
Some of the exclusives ( [x!], [b!], [p!] ) will barely be seen by regular system users...
On creation of new files or folders, the following default permssions are set:
rwma-- for ur----- for g------ for o and pEach permission group contains of 8 bits:
- the meaning of the "special" and "streaming" bits should be self explanatory from the list below...
- the "binary" bit indicates, that some binary execution is involved: whether the file is executable, a stream is of binary data,
a link has to be executed before retrieving the linked destination...
The first four bits are assigned directly, the combination of the other four work as below:
All four permission groups together are contained in one 32 bit word.
| 32bits | | 8bits | 8bits | 8bits | 8bits | | rwmax! | rwmax! | rwmax! | rwmax! | | user | group | others | public |
The inode header is 64bit-aligned (and fractions of 64)...
The inodeId is 64bits long,
permissions, user, group and creator ids are 32bits long,
. . .
| 64bits | 64bits | 64bits | 64bits |... | | 4x8bits | 32bits | 32bits | 32bits | 32bits | 32bits |... | inodeId | rwmax! | userId | groupId | creatorId | dateTime |...
for more details, see [ rwmax! - system components ] iNodes
© Siggi Gross - June 2024 - mail@siggi-gross.de
[ Legal Notice | Impressum & Datenschutz ]
