Aaron Stone wrote:
Paul J Stevens <[EMAIL PROTECTED]> said:
Aaron Stone wrote:
Oh, that's perfect then. So the next question is what steps would we want
to take in the dbmail utilities to restrict access to add/modify/delete
users, maintain the database, etc?
That's easy. You've already added the -f switch to all tools. So you can
already use different configs for different tasks using different
db-users with different privileges.
Interesting, but not what I'm getting at. I'd like to have
non-administrative, untrusted users able to hold accounts on a machine
running DBMail and not have the risk of them mucking around with DBMail's
database.
[snip]
But what started this thread was the current misconception in the acl
code that assumes a 1-1 relation between a mailbox, a user, and a acl
mask. There's simply no concept of group logic in the current code.
Oh, that doesn't sound good. Ilja's hip to the ACL code, hopefully he'll
have more insight on how to deal with the issue that you've raised...
That same problem isn't just in the ACL code. It's more of a problem
with the whole way users are managed in DBMail. There are no groups. We
have 'client_idnr', but that's no such thing as a real group. You can't
be a member
of several groups for instance.
With that in mind, I don't see any way that groups can be supported in
our ACLs. Of course, it would be really nice to be able to create groups
and give users access to mailboxes based on group membership. If we do
that, it would be completely logical to extend our ACL-scheme to work
with it (if groups are implemented, this would actually be fairly easily
implemented).
As I see it now, we're up to par with RFC 2086.
quoting from the RFC:
"
It is possible for multiple identifiers in an access control list to
apply to a given user (or other authentication identity). For
example, an ACL may include rights to be granted to the identifier
matching the user, one or more implementation-defined identifiers
matching groups which include the user, and/or the identifier
"anyone". How these rights are combined to determine the user's
access is implementation-defined. An implementation may choose, for
example, to use the union of the rights granted to the applicable
identifiers. An implementation may instead choose, for example, to
only use those rights granted to the most specific identifier present
in the ACL. A client may determine the set of rights granted to the
logged-in user for a given mailbox by using the MYRIGHTS command.
"
Ilja
--
Ilja Booij
IC&S B.V.
Stadhouderslaan 57
3583 JD Utrecht
www.ic-s.nl
T algemeen: 030 6355730
T direct: 030 6355739
F: 030 6355731
E: [EMAIL PROTECTED]
