#197 UNIX Permission system from CORE to modules and inheritance:

XOOPS_2.x
open
nobody
None
2
2012-09-25
2006-01-28
XoopsGold
No

Hallo!

I was checking other systems and framework in this
regards. Hence I came to the following idea:

If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.

Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.

Therefore, it could be taken forward into various
modules. For e.g.:

If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.

This therefore would be seperate to the group permissions.

Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.

Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!

Discussion

  • XoopsGold
    XoopsGold
    2006-01-29

    Logged In: YES
    user_id=1329834

    Hallo Skalpa!

    I suggested earlier to have a module <> permission <> groups
    table linking. This message is here:

    http://sourceforge.net/tracker/index.php?func=detail&aid=1404819&group_id=41586&atid=430843

    Thinking on it, I thought that it would be better to have a
    strong permission system which is NOT module related but
    really PERMISSION QUALITY related. Here the best possibility
    is ofcourse Unix system as described above.

    OK, I checked in the db and found out which and where:

    IN the table xoops_group_permission

    ......gperm_name.......

    has been a place to play by all the module developers.

    This funny play has been going on since there has been no
    disciplinary and controlling sub_routines available in Xoops
    Core. If there was anathor table available to define the
    quality with the name

    ........xoops_permission_type...

    where the quality of Unix permissions would be stored, then
    the module developers would simply have to insert those
    numbers like 700 of 777 unix permissions. With this system
    the core and all modules would understand the system of
    permissions.

    Therefore, I suggest the following:
    1. --------------------------------
    Make a new table xoops_permissions_link

    perm_id perm_name perm_type
    1.........rwxr-xr-x...0755
    2.........rwxrwxr-x...0775
    3.........rwxr--r--...0744
    4.........rw-r--r--...0644



    1. Apply the quality of permissions to modules.

    There cannot be a group permissions assigned to a group in
    this theory.

    The modules would have the user, group and system
    permissions anyway. Hence,

    User = Site Account or vHost or $SiteGroup ist the
    owner/User of a module
    Group = Group within a site
    Other = Everyone, Server and system functions



    1. Table xoops_group_permission

      gperm_name Field Name change to >>> gperm_id

    May be this may be interesting to discuss! Shall I make a
    sketch with tables of this idea? Does this idea make sense?

     
  • XoopsGold
    XoopsGold
    2006-01-29

    Logged In: YES
    user_id=1329834

    Hallo!

    Very interesting. Was just surfing and found out that this
    what I suggested is really nothing new but has already been
    implemented. In this computer world have no surprises with
    similar situations! ;-)

    Here you can see:
    http://www.awf-cms.org/

    Ofcourse, I should have mentioned that in Xoops Core
    permissions, there cannot be execute permissions. Hence it
    could only be access, write and delete.