[rrd-developers] [PATCH 1/5] src/rrd_daemon.c: Switch to per-socket, per-command permissions.

[kevin brintnall]

On Mon, May 25, 2009 at 12:09:44PM +0200, Florian Forster wrote:
> On Sat, May 23, 2009 at 04:30:17PM -0500, kevin brintnall wrote:
> > Any ideas on how the authorization scheme may change once we have
> > per-user authentication (i.e. with client certs)?
> 
> my plan for authentication was something along these lines:
> 
>   -P flush,stats/flushall,update
> 
> All commands before the slash (`/') can be used with or without
> authentication, the commands following the slash can only be used when
> authenticated. In this case `flush' and `stats' can be used without
> authentication, `flushall' and `update' require authentication, other
> commands cannot be used.

I think the argument ordering is potentially confusing.  Overloading the
-P argument may be even more so?

> This doesn't work with a per-user authorization setup, I'm afraid. To do
> that, we could adopt a slightly different argument syntax:

I was thinking embedding the user privileges somehow in the client
certificate?

>   -P [user0[,user1[...]]=]command0[,command1[...]]
> 
> For example:
>   -P flush,stats -P foo,bar=flushall,update
> 
> In this example the commands `flush' and `stats' can be used without
> authentication again, the commands `flushall' and `update' may be used
> by the users `foo' and `bar' after they authenticated.
> 
> For a more complicated and/or fine-grained we should probably think
> about implementing support for a configuration file.

I like the idea of a simple configuration file..  the main reason is that
we're able to change it after startup.  Anything we put on the command
line is fixed.

Once we introduce "updatev" support, startup may contain a large I/O
penalty.  So, we should try to avoid things that require a restart.

-- 
 kevin brintnall =~ /kbrint at rufus.net/