[prev in list] [next in list] [prev in thread] [next in thread] 

List:       msql
Subject:    [mSQL] Applets, CGI, Applications X msql.acl
From:       Andre Augusto Cesta <aacesta () ahand ! unicamp ! br>
Date:       1997-02-01 17:48:24
[Download RAW message or body]

Hello Msql Users:

I'm a MsqlPerl user and now a MsqlJava user too and also a newby on
the list. 

I'd like to understand what are the meanings of msql.acl fields read,
write, host and access to: 
 
		1-  STANDALONE APPLICATIONS,
		2-  CGI, 
		3-  APPLETS,
		4-  THE MSQL monitor
		(Any other?)
 
I'd also like to know how can I restrict R/W access using: 

		A-  ACL file options,
		B-  Unix file permissions
		C-  WWW server login/password modules 
		(ex apache compiled with mod-auth)
		D-  An Intranet httpd server
		(Any other way?)


First let me give some information about my installation:
//        msqladmin version       1.0.16
//        mSQL connection         Localhost via UNIX socket
//        mSQL server version     1.0.16
//        mSQL protocol version   6
//        mSQL TCP socket         4333
//        mSQL UNIX socket        /tmp/msql.sock
//        mSQL root user          msql
//        Host Architecture       Solaris-2.5-Sparc

Imagine the following:

The SAME machine works as a WWW server, Msql server and Intranet server,
and you want to control READ/WRITE capabilities for basically three
 groups of users:

		Intranet Administrators,  
		Intranet Users,  
		WWW Users.

They all would NOT like to use Msql monitor to access the database, 
they would preffer customized (and also more plenty of bugs) applets,
applications and cgi's to work with the databases through network from
different systems (mac,dos,etc).

(I think that more server machines would make the problem different. 
One machine running Msqld and other running WWW Intranet server, maybe
a third running a WWW server)

The .ACL File permissions you may be using on databases are like:

 read=* or  read=me,msqladmin  or  read=httpdaemon    ...
write=* or write=me,msqladmin  or write=httpdaemon,me ...
host =dcc.unicamp.br or host = *.unicamp.br or host= * or 
access=remote  or local or local,remote

---------------1-STANDALONE APPLICATIONS BEGIN------------------
If a user is running an application to connect to the database. 
To restrict access I'd rely on:

	A-  ACL file options,
	B-  Unix file permissions
	
I could create UNIX groups: IntranetAdmin, IntranetUsers, WWWUsers and
set -----x--- and group for the applications. Reminding also to set
read=login for each user on the databases listed in the .acl file. This
would suffice for local access.

What's the role of host= and acess= local/remote on this case?
HOW does user names on read=login write=login,-root relate to
people doing remote access to the database? Can I allow R/W
for internal users through network and read access for any 
remote application on the specified hosts, with security?
----------------1-STANDALONE APPLICATIONS END--------------------




----------------2-CGI-BEGIN--------------------------------------
If I'm considering someone running a CGI to connect the database, the
user running the CGI script will be the user of who installed the WWW
server and not who is browsing and performing posts and gets on the 
WWW server. 

In this case the solution I found to restrict access was to rely on:

	C-  WWW server login/password modules 
	(ex apache server compiled with mod-auth).
	The www server knows a login and encripted password 
	file and it requests and checks login/password before
	serving pages or running cgi's that are on private
	directories. You can check for user name (the one on the
	login and encripted password file) on the CGI enviroment
	variables and perform or not the resquest on the script	 			depending
on the user name passed as enviroment variable
	by the www server. 

	So you have to barriers: 
	One on the WWW server and the other on the CGI script.
	I really don't know how trustable are these 2 barriers.

	What's the meaning of access in this case?? I think it
	isn't usefull because the host running the CGI and the
	msqld are on the same machine. So it should work with
	access=local or local,remote.

	I think host isn't important for CGI's if msqld and httpd
	are on the same machine.
----------------2-CGI-END----------------------------------------


----------------3-Applets----------------------------------------

	If I intend to use just CGI I think access could be local, 
	but if I intend to use applets and network applications it 
	should be local and remote.

 	Is it right to say that for applets connecting from machines
	on the intranet I could just allow host=*.intranet.unicamp.br,
	and this would make it less dangerous? And for applets that
	must just read from db and be executed on any host? 
	What .acl would be secure?

	I know that applets can only connect to the host they came
	from. Is this important?

	What's the meaning of read=* or read=login for applets?
	And write=* and write=login?
----------------3-Applets-----------------------------------------

Putting It all together: Applets CGI and Applications, what kind
of .acl files could you have?


option=rfc931  //WHAT DOES IT MEANS?????



Thanks:
	Andre Augusto Cesta
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to msql-list-request@bunyip.com.  Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!

[prev in list] [next in list] [prev in thread] [next in thread]