Re: [Bug-myserver] ideas about how improve security file

[Daniele Perrone]

I think the second solution is better, maybe we can separate better
user definition and password from security policy using two kind of
XML files, one can be seen as a XML based DB that manage users, and
the other one as the actual security files obviously without many user
informations.  Anyway, I don't know the overhead that this solution
can introduce.

On Mon, Aug 25, 2008 at 12:47 PM, Giuseppe Scrivano <address@hidden> wrote:t
> 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" />
>
>
>



-- 
Perrone Daniele