bug-myserver
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-myserver] ideas about how improve security file


From: Giuseppe Scrivano
Subject: [Bug-myserver] ideas about how improve security file
Date: Mon, 25 Aug 2008 12:47:43 +0200
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

Hi all!

I would like to improve the security file, especially I would like to
define some attributes directly there, this is what will keep me busy
for the next future. :)

Now it is possible to define attributes in 2 places, global myserver.xml
file and vhost configuration.
At the end there will be 3 places where it will be possible to define
attributes: security file, virtual host configuration, general
myserver.xml configuration file.

Some APIs will help to find a value, imagine something like:

env.getValue("key", SECURITY_GLOBAL | SECURITY_VHOST | FILE_SECURITY).

and it will look in the following order:
SECURITY_FILE -> VHOST -> GLOBAL FILE

the first not-null value will be used by MyServer.


This is an example for a security file:

<?xml version="1.0"?>
<SECURITY>
        <HTTP TRACE="ON" />
        <AUTH TYPE="Basic" />

        <ATTR name="key" value="something" />

        <ACTION name="Host" value="localhost">ALLOW</ACTION>
        <USER NAME="God" PASS="godpassword" READ="TRUE" WRITE="TRUE"            
    BROWSE="TRUE" EXECUTE="TRUE" />

        <!--This is the setting for the Guest user-->
        <USER NAME="Guest" PASS="" READ="TRUE" BROWSE="TRUE"/>

        <!--Another user-->
        <USER NAME="Tim" PASS="Tom" READ="TRUE" EXECUTE="TRUE"                  
             BROWSE="TRUE"/>

        <ITEM FILE="file1" READ="TRUE" WRITE="FALSE" EXECUTE="FALSE">
                <ATTR name="key" value="something_for_file1" />
                <ACTION name="Host" value="remote">DENY</ACTION>
                <!--Define a file and its permissions-->
                <USER NAME="Jim" PASS="Morrison" READ="TRUE"
                         WRITE="FALSE" EXECUTE="FALSE">
                        <ATTR name="key"
                         value="something_for_jim_on_file1" />
                </USER>
        
                <!--Define the user permissions for the file-->
                <USER NAME="Bob" PASS="Marley" READ="TRUE"
                     WRITE="FALSE" EXECUTE="TRUE" />
                        <ACTION name="Host"
                                value="localhost">DENY</ACTION>
                </ITEM>
</SECURITY>

The ATTR field doesn't exist yet, this is the point of my doubt, in a
security file it will be easy to define a different value in relation to
the provided identification and the accessed resource.

For example the env.getValue API on this file will give a different
result if the user is not logged, if it is trying to access file1 or if
it is logged as Jim:Morrison and tries to access file1.
In the first case it will give "something", in the second
"something_for_file1" and in the third "something_for_jim_on_file1".

Beside implement ATTR, I would like to improve the security
implementation with supports for LDAP and PAM at least (later we can
think about keep passwords in a database too), how can we keep the
mechanism of attributes I showed before with them?
How we can mix security files configuration with LDAP or PAM?  We need
to avoid to duplicate information, like have the same user:password
defined in two different places.

Some solutions I see: use only the ATTR that are not defined for a
specific user (the global and the one in item) or  another, that I think
better than the first, don't consider the password but only the accessed
resource and the user name, it will be responsibility of other
mechanisms, LDAP/PAM/DB/.., to ensure the user can really access that
resource.

Expanding the access mechanism can be done adding another plugin type,
so it will be possible to add new mechanisms directly as plugins, but to
before proceed I need to have clear ideas about APIs and their
interfaces with the MyServer core.

What do you think about all of this?

Giuseppe

P.S.
These lines will use ATTR as soon as it is implemented:
<HTTP TRACE="ON" />
<AUTH TYPE="Basic" />

becoming something like:

<ATTR name="HTTP" value="ON" />
<ATTR name="AUTH" value="Basic" />




reply via email to

[Prev in Thread] Current Thread [Next in Thread]