Re: Perl->PHP Object Security

[Aaron Turner <aturner@linuxkb.org>]

On Thu, 20 Jan 2000, Jason Pincin wrote:

> Here's some more thoughts and some things I didn't touch on.
> 
> In order for these Perl script to operate fully under the current security
> model, they cannot change the DB at all themselves.  All modifications

Agreed.  I can only do queries from Perl.

> would have to go through the php-gateway.  They could however perform
> queries and provide information without going through php.  So long as
> they are not returning user info or anything like that :).  Which they are
> not... Aaron is coding this app to only return info on Object Types 1, 3,
> 5, and 7.  KB-Root, KB-Containers, Applications, and External Links
> respectively.

In the future this script (or another based on it) will also take type 6
(articles).  Perhaps we will also want it to manage the user objects too.
Regardless, we need to treat the security of this in the same way.

On a side note: Realize that we need to figure out a way to take the DB on
Vodka and sanitize it for when we release the code/DB to the world come
Feb. or people will get user info anyways.  We need to have some "dummy"
accounts an populate the developer DB with that info.


> The other option for authentication is to allow Perl to pass the object ID
> of the user performing the opperation, or in other words, the object ID of
> the user the opperation is ATTEMPTING to perform under... and securly
> passing the password along with that.  Then PHP can do the auth.

I still don't understand why Perl can't pass the username/password in the
http-auth header of the request and have PHP authenticate against that.
Basically you'd run the perl script with a cmd line option like:

-authinfo aturner:mysecret

> Don't know how we'd secure the password passing.  Perhaps fire off a
> single apache process that only answers to localhost or yukon?  Thoughts?

Yech.  How secure does it have to be?  SSL/PGP secure?  Or just some kind
of password I know and send over the wire?

Here's an idea:

Have a CGI interface to the CVS tree for the DB Perl dump.  Basically, it
would be a page of off admin (so it's SSL and user auth) and the user can
browse the different versions of the DB dump in CVS (via web cvs).  Then
they can pick a version to actually publish to the DB (so you can backout
of changes if you like).

So the process would be:

1) Downlaod CVS Perlized DB export
2) Convert Perl export to filesystem structure
3) Make modifications
4) Export filesystem structure to Perlized DB export format
5) Commit changes to CVS
6) Go to web interface, and publish to the DB.

The process that does the actual DB modification would inherit the users
authinfo.  So even if Joe made a change in the CVS image to a category he
doesn't have rights to, the system won't let those changes into the DB.
It would be a matter of doing a result code check of each insert/update to
find "authorization denied" and put that to a log which then could perhaps
be used to generate vote requests.

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://www.linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
The difference between `Unstable' and `Usable' is only two characters: NT