[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: access control (was Re: modular database backends)
From: |
Peter Novodvorsky |
Subject: |
Re: access control (was Re: modular database backends) |
Date: |
Wed, 13 Jun 2001 21:47:41 +0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; 0.8) Gecko/20010320 |
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.