Automatic for the People!

Note: while the rest of the document should be treated as preliminary, subject to change and everything, this chapter is preliminary preliminary! Anything described here might change, or be dropped.

Now that ARM provides you with ways of setting, organizing and querying authorization metadata everything an application needs for authorization should be on board. Which is great, of course, but couldn't we simplify things even further? Well, you know that is a rhetorical question: we wouldn't ask if we didn't have at least some answers:answers.

What makes Unix' authorization so easy to use? (relatively speaking: ityou iscan still even easier to get something wrong and tocompletely blow security completely.)security.) Unix implements basic file authorization on the OS level, thus every application gets its benefits when working on files. If a program reads from or writes to a file it is not up to the application to check whether or not the active user is allowed to do that. The operating system does it instead. To accomplish this Unix defines three default modes – or roles, as we ARMed people say – “reading”, “writing” or “executing”. It organizes the system users in a way, which allows for a quick scan of the current user's relation to the file in question. This approach results in two things: security – given that the Unix kernel is flawless security shall never be compromised – and ease of use: the overwhelming majority of Unix developers will never have to care about file permissions. And that more or less everything on Unix is a file or can be treated as such comes quite handy, of course ;-)

At least this comfort we can provide you with. “Auto-arm” your model via

acts_as_rolemodel :auto, :dummy => <something>, :initial_roles => <something>

This extends your ActiveRecord::Base class to honor some predefined system roles at the right time. While this is not bulletproof – still find_by_sql can conquer anything ;-) - it will help you not to shoot you in your foot. The following presents our predefined system roles and when they are checked:

• If Klass.find is called without a :rolesparameter it automatically checks for :read and :writeroles. Objects, that do not permit the current user to :read will not be returned by find. Instead a dummy object (as defined via :dummy) or nil is returned. Returned objects that do not allow the current user to :write will be returned in a read-only state: you can change these in memory, but once you try to save them to the database ActiveRecord will throw an exception. If find is called in a context where it is not allowed to returned nil but had to due to missing permissions it throws an exception.

• Klass.destroy checks for the :destroy role and throws an exception, if an object cannot be destroyed by the current user.

• Klass.create checks for the :create role on the system object Klass and throws an exception, if an object cannot be destroyed by the current user.

• Permission.blabla checks the :manage role on the object.

• Klass.create activates some default roles on the newly created object for the current user, if the current user is not :root. (As :root is permitted everything there would be no point in it). The set of roles is defined via Klass.roles_on_creationand defaults to :read, :write, :manage and :destroy.

Please note, that roles are not checked on each DB related activity. Most notably one can circumvent role checking via find_by_sql.

Configuration

arm.unarmed_when_testing