Re: [Phpwiki-talk] To clarify re:security question

[Jeff D. <da...@da...>]

I think it's great your working on this Reini!

Here's a few comments:

On Sat, 17 Aug 2002 12:29:04 +0100
Reini Urban <ru...@x-...> wrote:

> Just a note that I'm just testing some userauth code I've written.
> 
> * unix like filesystem permissions per page,

 There was some discussion about this awhile ago.  Basically the
 two reasonable choices seemed to be a unix permission model
 (which is simple and understandable for us unix geeks),
 or a more windows-like access control list
 (more familiar to windows guys (maybe), offers more control,
 probably a bit harder to code...)

> * a user and group table,

 This seems hard to get around, no matter what, but certainly
 adds complexity and ugliness...  I think there were ideas
 before about keeping the group membership data in wiki pages
 (as wiki text).  Something like, if PhpWiki wants to check to
 see if JohnDoe is a member of LunchGroup:
   1. Look at wiki page UserGroupLunchGroup (or something).
   2. Make sure that that has reasonable permissions and ownership.
      (In the current perm model: it must be locked.)
   3. Look for the line:
          * JohnDoe
      (or similar) within the text of the page.

 This avoids new tables, makes it easy for the admin to edit
 the group tables, and makes (possibly) public accessible group
 membership lists.

> the mysql schema:
> CREATE TABLE user (
>    userid int(10) unsigned NOT NULL auto_increment,
>    username char(16) binary NOT NULL default '',
>    password char(16) binary NOT NULL default '',
>    PRIMARY KEY  (userid)
> ) TYPE=MyISAM;

username should be (enforced) unique.

char(16) may not be enough.  I think it would be nice to use
wiki-words, like JeffDairiki as userids, and reasonable ones
could easily be longer than 16 characters.


> INSERT INTO user VALUES (1, 'ReiniUrban', 'somecryptedpassword');
> CREATE TABLE member (
>     memberid int(10) unsigned NOT NULL auto_increment,
>     userid int(10) unsigned NOT NULL default '0',
>     name char(16) NOT NULL default '',
>     PRIMARY KEY  (memberid),
>     KEY userid (userid)
>   ) TYPE=MyISAM;

I'd suggest, instead, two tables (based on /etc/group)

CREATE TABLE group (
      name char(16) NOT NULL,
      groupid int NOT NULL auto_increment,
      PRIMARY KEY (groupid)
)

CREAT TABLE members (
      userid int NOT NULL,
      groupid int NOT NULL,
      KEY userid (userid),
      KEY groupid (groupid)
)

Or better yet, the group-tables-in-wiki-pages idea outlined above.
        

> INSERT INTO member VALUES (1, 1, 'admin');
> CREATE TABLE permissions (
>    pageid int(11) unsigned NOT NULL default '0',
>    userid int(11) unsigned NOT NULL default '0',
>    memberid int(11) unsigned default NULL,
>    permission int(11) unsigned NOT NULL default '776',
>    PRIMARY KEY  (pageid),
>    KEY userid (userid),
>    KEY memberid (memberid)
> ) TYPE=MyISAM;

Permissions/ownership information can easily be stored
in page meta data.  The current WikiDB backend supports
attaching arbitrary key/value pairs to each page
(and also each page revision).
The interface is through the WikiDB_Page::get()
and WikiDB_Page::set() methods (see lib/WikiDB.php).

The only issues with doing this are:

  If any sensitive data are stored that way (e.g. passwords),
  the _DebugInfo plugin (among possibile other things) will
  have to be fixed so that that information won't be
  exposed to prying eyes...

  Pick keynames which won't clash with other key names.
  We need to come up with better docs about what keys
  are used, and a system for picking new names, but
  I think most/all of the currently used keys are 
  listed in the docs in WikiDB.php.

  One can't search the db (efficiently) for meta data.
  I don't think this is a big issue in this case.
  It will make operations like "show me all pages
  owned by JeffDairiki" slow (linear search), but
  I don't think that's a big deal...


Other issues to think about:

Self Registration

  It has been a long stated goal of PhpWiki to implement an
  automatic self-registration system where new users can 
  register themselves, along with their e-mail addresses;
  Then their initial password is mailed to their e-mail
  address (or some other similar scheme) --- they idea
  being that by making sure everyone at least has a valid
  e-mail address, you avoid completely bogus/untraceable
  users.

  When/if this gets implemented, we'll need to be able to
  store other "user meta-data" in the user table.  (E.g.
  e-mail address.)

User Table in Wiki Page(s)

  You suggested this too.

  I have yet to see a clean way to do this, but it would sure
  be nice to have this as an option.  The big attraction
  of this is:
    * It's easily/guaranteeably portable to any server/platform
      which supports PhpWiki.
    * The mechanism for editing the user data is already built
      into PhpWiki.
    * (If done right) public user information is automatically 
      publically viewable (& searchable, etc...)

  An idea on this lines (which I think I still favor) is to 
  have one page per user.  The page name is the username.
  Password and other sensitive information is stored in the
  page meta-data.  (Anything stored in meta-data will take
  special code to edit.)  All non-sensitive information
  is stored in the wiki-text.  This has been discussed before,
  and I remember that not everyone was as excited about the idea
  as I was...