Briggs, Gary wrote on Wed Aug 22 10:27:50 2001:
>
> Hmmm. This is of significance to me, as I work in a secure environment...
>
> I'm not sure how much compute power and secondary storage you have, but in
> the end, if it's possible, my humble recommendation is to have two
> databases, and use some webserver/htaccess voodoo to arrange so that outside
> people
> see a different search page/database backend to internal people.
I do not wish this solution. It increases significantly disk storage,
computing time and network ressources.
>
> Of course, depending on resources, you might like to implement that at the
> database layer with some sort of balancing in it, but we're talking hideous
> implementation details by now...
>
> If that's not viable, I'm working on a wholesome way of adding ACLs to the
> engine, but it's not a simple exercise to work out what the ACLs need to be,
> especially on the scale of many many thousands of URLs.
these ACLs might operate only on the tags or categories. Which reduces
the complexity.
> That would also require an authentication method on the search page, which
> is intrusive... NTLM is NOT my friend, before you mention it (=
Using several symbolic links on search CGI, each having his own
template (search.htm), you might use access controls for each symbolic
link in a unique .htaccess, without increasing space for this CGI.
>
> And along the same lines, are you using mySQL? [I plan to move to SyBase at
> some point in the future, but until then...]
> If so, how have you implemented the security of the database user for
> /searching/ being effectively read-only, and the indexer/admin user being
> rw? I've basically created a HUGE permission list, but I feel that's
> probably not the best solution...
First of all, our database has an user/password, and is used by
the webserver which works on a dedicated account. Thus there is no
risk of intrusion.
MySQL has a privilege mechanism which makes it to have several
user/password accesses for each database, table and column, each
user/password having his own privileges. Thus an user/password can
update the database whereas another can only consult it (select statement).
>
> The problem, you see, is that the read-only user needs to be able to create
> and drop tables, and have write access to some parts of the qtracking table.
> [note: only some parts of it, because I have greatly enhanced the qtracking
> here, and have several daemons running that are finding further information
> about the users than just what they give]
It seems that the privilege mechanism of MySQL should be able to solve
this problem.
Dominique
>
> Gary (-;
>
> PS e-mail me personally if you want snippets of source code, etc. In fact,
> feel free to e-mail me personally about this anyway...
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 21, 2001 6:27 PM
> > To: [EMAIL PROTECTED]
> > Subject: security: private or public pages
> >
> > Hello,
> >
> > I wish to do so that, from one side the whole set of documents from
> > our site be normaly referenced and retrieved when looked from one of
> > our team users, and, from the other side that any external web visitor
> > only see the references to public document. As the spider is working
> > from inside the site, access controls are not efficient. More
> > specifically, the research engine may provide references and display
> > pages strictly for internal use.
> >
> > One solution may be to use tags or categories, but, during research
> > stage, it may still be possible to hack the URL in order to suppress
> > the CGI research limiting parameters (t=, cat=).
> >
> > Another way to overpass this problem would be to constrain in the
> > template file part (<!--variables ... -->) the CGI parameters that we
> > want in order that they cannot be suppressed or overriden during a
> > research. However it would still be possible to short-cut this solution
> > with the "tmplt=" CGI parameter, but in case where the restriction is
> > added as a defect option in the template, the protection seems enough
> > since it is not possible to guess the name of the other templates.
> >
> > What do you think about this ?
> >
> > Sincerely.
> >
> > Dominique Asselineau
> > --
> > +------------------------------------o------------------------------------
> > -+
> > | P-mail: | E-mail:
> > |
> > | E.N.S.T. - Dep. TSI | [EMAIL PROTECTED]
> > |
> > | Dominique Asselineau | Phone: (33/0) 1 45 81 78 91
> > |
> > | 46, rue Barrault | Fax: (33/0) 1 45 81 37 94
> > |
> > | 75634 PARIS Cedex 13 - France |
> > |
> > +------------------------------------o------------------------------------
> > -+
> > ___________________________________________
> > If you want to unsubscribe send "unsubscribe general"
> > to [EMAIL PROTECTED]
> >
>
>
--
+------------------------------------o-------------------------------------+
| P-mail: | E-mail: |
| E.N.S.T. - Dep. TSI | [EMAIL PROTECTED] |
| Dominique Asselineau | Phone: (33/0) 1 45 81 78 91 |
| 46, rue Barrault | Fax: (33/0) 1 45 81 37 94 |
| 75634 PARIS Cedex 13 - France | |
+------------------------------------o-------------------------------------+
___________________________________________
If you want to unsubscribe send "unsubscribe general"
to [EMAIL PROTECTED]
