Hmmm. Well, yes. But at the same time, it's considerably more secure than
anything else you'll be able to do...
And while the ACLs _could_ work on just tags or categories, I'd rather
define them as groups of URLs as that would have a greater degree of
flexibility... I'd ideally like full regexp support...
And finally, the database security: yeah, I've done it so that it works. But
when they search, the algorithm actually involves CREATEing a table,
SELECTing some stuff into it, and the DROPping it again afterwards.
Bugger.
Gary (-;
PS If you're interested, I can send you a sanitised version of the mysql
database...
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, August 23, 2001 4:23 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: security: private or public pages
>
> 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------------------------------------
> -+
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
___________________________________________
If you want to unsubscribe send "unsubscribe general"
to [EMAIL PROTECTED]
