[ /rwmax.html ]

rwmax! extended permission control

current status: [ r w x ] for [ u g o ]

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.

the current status : rwx

files :
r - read the file contents
w - write, delete the file and its contents
x - execute the file/script
folders :
r - read the directory content
w - create, delete files in the directory
x - enter(cd) and execute files from the directory
this leaves some uncovered spots and ambiguities when You want to allow/disallow certain operations.

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 current status : uId, gId

the owner of a file is defined by its uId,
ths group of a file is specified by its gId.

the current status : ugo

u - owner (set by uId or user name)
g - group (set by gId or group name)
o - others...
...expecting others to be anyone on the system. there is no differentiation between authenticated system users or any network/server connected (maybe anonymous) user.


extension objectives:

additional permission levels:
[ u g o p ]

u - owner (set by/checked against - uId)
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)
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...

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)

additional ownership fields:
[ owner group creator ]

owner - by uId - the effective owner of the file
group - by gId - the assigned group of the file
creator - by uId - the creator of the file
for collaborative environments files will be edited/changed by multipler users.

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.js
although the above expample may be a bit simplified:

- the file owner remains, permissions untouched.
- additional data stored: WHO made which changes at a specific dateTime.
- please note, the number of elements increased also.

following the backlog of the current file to each of its precedessors does reveal its previous versions.

in situations, where a better defined versioning with diff/merge is preferrable, we could do the following:
// 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.js
again, this might be a bit simplified for a better explanation...

additional permission accessors:
[ r w m a x! ]

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

[ r ] - read

reading permission - should be self explanatory
anyway, reading permission includes the right to:

in case of folders:

[ w ] - write - locking!

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.

[ m ] - modify

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 !!

[ a ] - append

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.

[ x! ] - extended execution

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].

-
regular file
x
executable
f
folder
l
link
s
stream
b
stream - binary
p
stream - process (its stdIO streams)


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.

[ ! ] - the exclusive bit

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 !

-!
file locked

by adding a [!] to one of the above letters,
the corresponding special file is marked exclusive as follows:

x!
exclusive executable (core modules)
f!
exclusive folder (the basefolders of the root fs)
l!
exclusive link (hidden)
s!
exclusive stream (/dev)
b!
exclusive stream-binary (/mem)
p!
exclusive stream-process (session & core stdIO streams)

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.

!!
hidden

!! 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...

default permissions

On creation of new files or folders, the following default permssions are set:


the technical bits and pieces

Permissions :

Each permission group contains of 8 bits:

r
reading bit
w
writing bit
m
modify bit
a
append bit
-
exclusive bit
-
streaming bit
-
special file bit
-
binary bit

- 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:

0 0 0 0  [--]
regular file
0 0 0 1  [x-]
executable file
0 0 1 0  [f-]
special file -> folder
0 0 1 1  [l-]
special file binary-> link
0 1 0 0  [s-]
stream
0 1 0 1  [b-]
stream binary
0 1 1 0  [p-]
special stream -> process stdIO
0 1 1 1  [q-]
reserved for reqs, queries & interrups
1 0 0 0  [-!]
exclusive file -> locked
1 0 0 1  [x!]
exclusive executable -> core modules
1 0 1 0  [f!]
exclusive special file -> baseFolders of the vfs
1 0 1 1  [l!]
exclusive special binary file -> hidden link
1 1 0 0  [s!]
exclusive stream -> /dev
1 1 0 1  [b!]
exclusive stream binary -> /mem
1 1 1 0  [p!]
exclusive special stream -> session & core modules stdIO
1 1 1 1  [!!]
hidden file

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 |

inode header :

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 ]

Loading Application ...