Abstract

The following article outlines a convention for unix system accounts that allows fundamental business entities to be defined such that access to and permission for these entities can be defined in a consistent and reliable manner using nothing more than the standard unix file system permissions. An excellent side effect is that it also defines a storage structure based around those entities (as directories will generally be created along with the system accounts we use) which, in turn, relates to backup and data lifecycle management and security processes.

Why do we need a convention?

This is a fairly notional argument and the short answer is that you don't. The "need" for organisation is a philisophical dictat that we're not going to engage here and, in many instances, a strict strict "no-method" would be more effective -- that is to say that an ID is an ID and there is no association between that and the system's use of that identifier.

This is, in fact, the reality; your systems will simply treat the identifiers unique, numerical identifiers

However, that "no-method" still requires firm control of the notional entities relating to those identifiers and so we generalise this process to give ourselves abstract boundaries.

This proves very effective for a couple of reasons. We have numerous, small clients with a few user accounts and often no business structures in place; as part consulting in that environment it has proven very useful to impose a notional structure on the business; thus creating a place for all the elements that are held in people's heads. A very important part of this process is the definition of roles within the business and thus application of people to roles -- again, something that is often undefined.

It also allows us to centralise user-accounts (and IDs to our core services - i.e. login, file services, email, etc).

Comparison to ActiveDirectory and Novell

ToDo

Unified system 'entity'

One fundamental aspect of our strategy is to unified the notion of a system entity; that is to say that we have no use in distinguishing between users and groups. A system-entity will have a user component and a group component; only IDs under 1024 may break this convention as these are essentially system entities and may be used by the system in whatever manner is appropriate.

This is nothing revolutionary of course, we simply extend it from the notion of a 'user' to include the organisational and operational entities that we need

These would often have been defined as 'groups' rather than as a user and a group

. We are thus able to include, by group membership, logical relationships between all the entities in the system.

The precise relationships are not defined at this point.

Basic identifiers

Unix system identifiers are numerical, running from 0 to 65536. Extended identifiers (used in most modern systems) go far higher, however, for our needs (and compatibility reasons) it suffices. Thus IDs above 65536 are currently undefined, although not reserved

The current intention is to repeat the "power of two" mappings for the next 16 bits and thus create a two distinct sets of IDs; compatibility and extended.

It should be noted that no identifier is "reserved", these define conventions, not rules and thus any system will correctly (within it's local operation) handle both numerical and name identifiers that do not conform to this specification.

The identifiers are broken out as follows:

| class | scope | start | increment | range | |~sys|system|0|+1|1023| |~local|system|1024|+1|1022| |~app|global|2048|+1|2046| |~ounit|global|4096|+1|4094| |~orole|global|8192|+1|8190| |~user|global|16384|+1|16382| |~__job|global|32768|+1|32767|

Which are defined as follows:

;~sys :base system accounts ;~local :local system accouts (i.e. local application accounts) ;~app :global systems/applications accounts ;~ounit :organisational units i.e. departments, customers, etc. ;~orole :organisational roles i.e. management, staff member, secretary, etc. ;~user :individual user accounts ;~__job :project or job accounts

Thus every system, organisation (and it's departments), the roles within those departments and the users (i.e. people) and the projects will have a unique identifier within our systems that will be used for various reasons, primarily the security of that entity's information.

There are a large number of considerations that arise from this, which I will discuss here in some detail but probably not completely.

==== Account naming conventions

As we may have already deduced there are two identifiers that uniquely identify an entity within the systems. The UID (or user ID) and the user name. The user name is the convention we use for most actions with the UID being restricted to internal system operations and thus we generally don't know (and is generally irrelevant as long as it is unique), thus our primary consideration is with the naming conventions.

Our goals are to have unique, non-conflicting, non-preferential names for all of the entities listed above, whilst still allowing for implicit indication of structure within those elements. These must all be contained within 16, 7-bit characters allowable by the majority of systems for account names. As such we restrict ourselves to the following character sets:

lower case latin letters[a-z]
upper case latin letters[A-Z]
numerals[0-9]
under score[_]
hyphen[-]
period[.]

Whilst this is quite restrictive, expressively, it is more than adequate for our purposes and by using neat canonical forms we can meet our 16 character limit.

====== free form account classes and general conventions

the first three classes defined above, sys, _local, and _app are all free form classes in that, as long as they restrict themselves to the defined characters, they may be of any length or pattern. However, we strongly encourage following the following conventions.

Always use a terminating numeral such that iteration of services with the same name may be accommodated and this may be extended to two numerals should the expectation of large numbers of conflicting service names be expected. It is always important to note that the definition of the "comment" within the systems is expected and thus 'http0' and 'http1' may not tell us a great deal about the service but investigation of the "comment" should identify which service performs which actions.

nb: 'http00' and 'http01' may be useful if large numbers of web services are executing ""']]

Also we generally restrict the use of mixed case specifically for breaking the names into different classes of identifiers. So, for example, if we needed a single character iterator but needed more than ten we might use the convention '[a-z]{1,7}[A-Z]' instead of our more common [0-9] terminator. We also often extend numerical identifiers (i.e. job numbers which are actually numbers to use hexadecimal numbering when it appears that we may exceed our intial expectations, in these cases we use upper case lettering. For these reasons, and for general clarity, we discourage the use of mixed case identifiers unless justified by reasons beyond, "looks cool" (even though that's probably the best reason for anything).

== fixed class definitions

==== Organisational unit

Most of the classes really require little description, however, the organisational unit, as it carries most of the structure for the remaining elements may appear complex. However, we are pretty sure that one enough examples have been seen it's simplicity (and clarity) will be apparent.

The 'ounit's eBNF is as follows

[[!format bnf

but since that structure probably means little by itself the following table breaks that down into the relevant sections.

bs0ie0, bs0ie1, bs0us0
class ebnf notes examples
__ounit (primary) [a-z]{2}[0-9] here we will generally use the first character of the organisation's name followed by a discressionary letter from the organisation's name that will serve to make the mnemonic as memorable as possible. the numeral at the end may be used to ensure unquieness. in the event that the preferred mnemonic is "full" (i.e. the numbers 0-9 are all used), another suitable (or even unsuitable mnemonic) should be used. bs0, bs1, os0, te0
__ounit (multiple and departments) <ISO-3116>[0-9] The first level of the departmental breakdown of organisational units should be the two letter ISO-3166 country code of the country in which that organisation resides, followed by another numerical identifier.
__ounit (discretionary departments) [a-z]{2}[0-9] There may be one further level of organisational breakdown added, when desired, that is discresionary. This allows for numerous departments within a specific companies, geographical entity to be treated as separate clients. ab0ie0en0: engineering
ab0ie0mn0: manufacturing
ab0ie1dv0: development
ab0ie1rs0: research
__ounit (alpha enumerator) [a-z] This discretionary 'alpha' enumerator at any level of the organisational unit's code, however it must be used consistently within each primary organisation. so, for example, if we use it at the top level 'bs0a' then we are saying that there will be too many 'bs' organisations and thus we want to extend the enumeration. this means that we will not be able to use the alpha enumerator at any other point for those organisations. We would strongly discourage the use of the alpha enumerator at the top level. It is important to note from the examples that the sets given for this example and the sets given for the example above are not identical. The first indicates that there two departments in 'ie', each with two departments in them. The second indicates that there are four departments in 'ie'. There is probably little functional distinction in these definitions. ab0ie0a: engineering
ab0ie0b: manufacturing
ab0ie1a: development
ab0ie1b: research

the primary three character identifier, identifies one company or organisation. thus everything that starts with 'bs0' is the same organisation, although by defining entities below it we treat those "departments" as separate clients.

must be flat at each level, ie you cannot define 'bs0' and then 'bs0ie0' if there is a departmental (or other) split, then those entities must also be defined completely.

organisational role

    [a-z]{2,3}[0-9].<__ounit>
    probably want to change this to plus sign '+'
NB: '__unit' may be canonical org name instead of full 'ounit' but this must be consistent within the primary org (i.e. you can't have some as 'ab0' and others as 'ab0ie0').
TODO: write this.
NBB: may have to limit this to two levels with the extra character which keeps it to 7 chars maxium for ounit - also limits the job to 16 (these 7 plus '-' plus 8 chars for job identifier).

users

    [a-z]{2,3}[0-9].<__ounit>
NB: exactly same rules as organisational role
NB: may want to change the delimiter character
TODO: write this.

jobs

    [a-z][0-9A-Z]{2,4}-<__ounit>
NB: the first letter will define the type of work
NBB: there is no explict reason to include the organisational unit. it may be better to exclude it, thereby limiting the characters to 8 instead of 16 (as i've stumbled upon a problem with NIS that may restrict this.
TODO: write this.