Author Topic: Security/Permissions  (Read 2463 times)

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Security/Permissions
« on: March 20, 2013, 01:10:10 PM »
So, I'm tinkering with Lil.  The goal is just to make a little I3 chat room thing, but since you have to rebuild it from the ground up, I'm trying to also make it a useful kernel others could build on.

I made a user/account system, and now I figured I should add in user/group security of some sort.

I always hated the typical LpMUD security system, as it tends to rely on fixed pathnames.  I'd rather have something more like VMS or more recent unix systems, where there's not just a concept of owner/group, but also an ACL list that can specify permissions for individual users/groups, not just the one that "owns" them.

So, at blue-sky level, the idea is to create a file daemon that holds permission info on various files and directories.  When you ask if a given user can do something to a file, the daemon can try to look that up directly, and if nothing is found, bubble upwards until it finds a match or a default.

So, groups are easy to define.  You can make "players", "wizards", "admin", and each project domain could have a corresponding group.  Since I plan to have accounts and characters as seperate things, those would also be things you'd have permissions available for.

When thinking about the actual permission entries themselves... each thing needs default permissions, and then one ACL list for allowed, and another for denied.  If the default permission is global read, no write, you could put an ACL to let joe and domain fooland write, and another ACL preventing the wizards group from reading.

For the permissions themselves, the usual read/write of course.  I also liked VMS having a seperate "delete" bit.  I think it also makes sense to have clone/dest permissions.  There may be occasions you want a wizard to be able to read or copy code, but not directly clone an object into the game, or be able to dest an existing object.  Further, being able to control function calls could be useful.

We all know valid_read/valid_write.  I'm thinking valid_object might help with the cloning issue.

So, the question is.. what all simuls would I need to muck with?  clone_object(),  new(), destruct(), call_other(), call_out()?

Feel free to make suggestions.  Right now, it's just an idea.

(Note that this is the permissions system itself, and is just meant to address "can X do Y?".  Determining the correct X is the job of the caller... which would be the simul_efuns that make use of the permissions daemon)

Offline Maze of Ith

  • Acquaintance
  • *
  • Posts: 33
  • Sometimes nothing can be a really cool hand.
    • View Profile
Re: Security/Permissions
« Reply #1 on: March 20, 2013, 06:48:07 PM »
I really like this idea. I just posted something relating to this TODAY!
http://lpmuds.net/smf/index.php?topic=1459.0

I am definitely interested in working on this, too! Maybe we can chat about sometime about ideas, etc?

I can be reached as Zed on LooneyII and Dead Souls Dev.

Cheers!
zed @ looney2.com 8888
zed <at> lilypadmudlib <dot> com

Offline Maze of Ith

  • Acquaintance
  • *
  • Posts: 33
  • Sometimes nothing can be a really cool hand.
    • View Profile
Re: Security/Permissions
« Reply #2 on: May 29, 2013, 12:52:29 PM »
Quix - I am working on something right now, and I will let you know how things go. I have opted for writing a daemon to handle everything. I hope that it works like I think it will, but who knows - I have never attempted anything quite like this.
Cheers!

Zed\Ith
zed @ looney2.com 8888
zed <at> lilypadmudlib <dot> com

Offline donky

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: Security/Permissions
« Reply #3 on: August 13, 2013, 12:37:14 AM »
So, at blue-sky level, the idea is to create a file daemon that holds permission info on various files and directories.  When you ask if a given user can do something to a file, the daemon can try to look that up directly, and if nothing is found, bubble upwards until it finds a match or a default.
I got away from the path names by adding a define parser to the master object.  This would index all the defines like TERRAIN_H and put them in a mapping to the real file name.  No code ever used hard coded file names, instead they all used defines.  And default permissions were defined in a custom configuration script, by define name.  Define names could be used anywhere file names could be used, even on command lines.  e.g. update TERRAIN_H.

The permission system wasn't limited to file access, but was shared for named actions.  Like adding a new domain, or promoting someone.

Offline Maze of Ith

  • Acquaintance
  • *
  • Posts: 33
  • Sometimes nothing can be a really cool hand.
    • View Profile
Re: Security/Permissions
« Reply #4 on: January 19, 2015, 04:54:23 PM »
Quix - I have forked your repo and have started updating some things. First commit was to resolve an issue with exec(user, this_object()); in the login.c get_password function. It is working now. I will be updating things as I move along and move some more code from my lil project (lilypad) to SuckingMUD to get it a little further along.

Cheers!
Zed
zed @ looney2.com 8888
zed <at> lilypadmudlib <dot> com