This project - Migrating/Moving to RBAC - "no looking back" is going to take "too much" time to organize the story into a single article, so instead - in the spirit of something you can read "in the Morning" with coffee and toast, or a croissant - I am breaking it into smaller pieces. My intent, when the series is finished, is to make a white paper from them. This is my "rather than wait..." approach.< /p>
The first article was RBAC does not replace DAC automatically. Here I shall start introducing is what DAC is - what are we replacing. And from the information here move on towards how it has been used for years, how a program such as sudo attempts to make us less dependent on a complex DAC model, and how DAC serves as the preferred protection model by black hats (as it is so easy to break! ;)
What is DAC?
If you search the web for a definition of discretionary access control (DAC) the common phrase that comes back is that "DAC is a method to restrict access to files and directories on systems". My first response is that they have the direction all wrong - DAC is a method to permit access; however, after consideration I concur that historically speaking "restrict access" is correct.
I want you to win you over to my preferred, more timely, definition where the key phrase is permit access. Why the focus on permit? Because in today's world we should not give access by default and then restrict access. Instead, just like in a firewall, we should start from a deny all and then specify exceptions to permit access.
Evolution of umask values
Way back when - 30 years ago - the default umask value was zero (0) - or no mask. That has migrated from masking world write right permissions (umask 002) to no group/other (other is current name for what used to be called "world") write permissions (umask 022), to no group write/no other access (umask 027) to what I call "Data Ownership", or no group/other access rights (umask 077).
What many people are not actively conscious of is that there are only three permission bits active at any particular moment. If someone says there are 9 or 12 bits he/she is looking at the data structure - not the effectiveness.
Three bits to manage access
The three bits are encoded in octal notation (values 0-7 are valid) where read is assigned the value 4, write the value 2, and execute/access is assigned the value 1. The sum of 4+2+1 is 7 so any combination possible fits within the bounds of three bits.
The key concept here is that on UNIX/Linux legacy filesystems there are only three permissions: read, write, execute for files; read (list), write (add/remove), access (search PATH, transverse PATH) for directories.
Yes, there are 9 bits regulating access - as three sets of three bits: set one: USER; set two: GROUP; set three: OTHER. Which set is active depends on your effective identity: if you are the owner of the object the USER set determines you current access rights;(else) if you are not the owner AND you have the object group id (gid) in your group list then the GROUP list specifies your access rights; else the OTHER bits specify your access rights.
For the very technical: some systems also support ACL (access control lists). An ACL might modify how the three bits of access rights are determined - but the number of bits regulating access remains three.
I don't want your coffee getting cold - more another day.