Re: access control (was Re: modular database backends)

[Peter Novodvorsky]

Milan Zamazal wrote:

> > > > > > "PN" == Peter Novodvorsky <address@hidden> writes:
>
>     PN> 1). i don't like that client can pass without authentication
>     PN> phase.  If he want to login as anonymous, he has to do it. IE,
>
>     PN> USER anonymous address@hidden
>
> Hm, are there any *real* benefits of this except it's annoying during
> debugging?:-)

Yes, I want to devide everything in several stages. One of them is 
authentification
stage (Like in ftp/pop3).

>     PN> 2). I don't like that check of user/password is made by gnatsd
>     PN> and not by "database driver". I mean that function that
>     PN> authentificates user isn't called by init_gnats that actually
>     PN> connects to database, but after it.  Access control is done by
>     PN> gnatsd, and not by database driver.
>
> IMO this is implied by the fact that there are actually several
> authentication methods in GNATS.  The "built-in" methods are file system
> permissions and the gnatsd mechanism.  Since gnatsd is supposed to be
> the only method of accessing GNATS through network, I can't see anything
> much wrong in that gnatsd performs *the* authentication

Yes, this is ok for current version.

>     PN> 3). There is no access control for query-pr, send-pr and
>     PN> edit-pr. This is close to the subject of 2)., because
>     PN> authentification is made on the side of client, not on the side
>     PN> of database.
>
> I'd consider this a feature.  It's sometimes useful to be able to access
> GNATS data based on the file system permissions.  If you don't like
> that, simply chmod go-rwx the database directory and force users to
> access the database via query-pr etc. connections to localhost, thus
> moving the authentication to gnatsd (single place).

OK.

>     PN> 4). I want that some bugs can be edited only by group of
>     PN> developers.  It can't be done in current version.
>
> I think this complaint is legitimate.
>
>     PN> Is it enough? ;-)
>
> Pardon my ignorance. :-) Generally, I'd be curious whether your problems
> come from a real experience or you just think only on a theoretical
> level.  

Some of them come for theoretical level, and some of them have real-life 
reasons.
Company I work for makes a distribution. It is maintained by my 
coworkers and some
people who volounteer. I want them to have rights to edit only their bug 
reports while
office people to edit any bug report.

> My experience with running BTS is that the more access control
> the more problems (the first one being users don't bother to use the
> BTS).  There is no access control in the Debian BTS and it works well.

Remember two things:
1). Debian is open project, it doesn't have competitives that want to 
spoil it's
buisiness.
2). Debian isn't commercial project and if BTS gets spammed and is down for
1 day, it is not critical while in company you loose one buisness day.

This is one of reasons why I decided not to use debbugs (another were that
it is very ugly perl with pieces of source code put in aj's home dir, 
and you
cannot find them in CVS :).

> I don't say some things shouldn't be improved but it's a low priority
> issue for me.  For instance, I consider the modular database backends
> problem much more important and useful than the access control features.

OK. In this case I was talking about non-existing GNATS5. ;-)

                                                                        
                             Nidd.