Hello.



First the background.

1: I have no control of the server.

2: The system admin is *very* hesitant to change the permissions of the folder containing the .mdb file so that IUSR can
read/write/delete files in the directory (he has fears, that a worm or something like that could exploit the ability to write in
that directory)



I can connect, and show data from the database, but I am unable to add or change information in the database.



The error I get is: 

Microsoft JET Database Engine (0x80004005)

Operation must use an updateable query.



I've been told this is because the IUSR doesn't have the right permissions on that folder.



The sys admin has asked that I find out if it is possible to create a session setup, that changes the username/password that is used
to access the database.



so basicly, the user logs in (which, as a .asp newbie, i've Yet to get working right) after the user logs in, instead of hitting the
server as IUSR they hit it as billy_Bob and password joe. (of corse billy_bob has the right permissions to write the lock file,
update the database, and delete the lock file).

 

is this possible?



If it is, how do I do it? Please understand that I'm a complete asp newbie, and I don't even know if I'm asking the right questions
!



Thanks in advance.

-Kevin

I think the short answer to your question is no, you can't change from 

being IUSER to another person.  If you think about it, if you can change, 

for example, from IUSER to Administrator all sorts of security problems 

could be involved.



That being said, I'm assuming your asp pages and database are in the same 

directory.  That's a bad idea, in my opinion.  I would put the database in 

a separate directory, off the root drive if possible (example: 

c:\webdb\appname\databasefile), give IUSER write rights to that and 

restrict write rights on the asp page directory 

(c:\inetpub\wwwroot\appname\aspfiles.asp)

Another solution would be to use NT authentication, period, for the 

website.  It would mean that your user would have to log in to your asp 

app as well, unless there is a way to share the current login information 

with the session object.



What that would mean is this



I go to www.aspapp.com/myapp



since the myapp application is in a folder that requires a login, I'd have 

to type in my login, password and domain information. Once that's done, 

your login page comes up (because you need to know who is there in your 

app) and the user has to do it again.



One of the drawbacks to this method is that, aside from having to log in 

twice, your sysadmin has to create these logins as well.  I don't know 

about you, but I don't want the hassles and headaches of having outside 

users with ANY access other than that conferred by IUSER.



To summarize, segregate your datastore from your presentation layer.  Set 

write permissions only on the folder that ONLY contains the relavent 

datastores, and restrict the heck out of anything else.  

Ok, I'm a linux guy, so what follows are probably entry level NT

questions:



1: Can NT authentication be used on a *section* of a site? or does it

have to apply to the ENTIRE site?

   ex: I have the following directory structure.

   /newsletter

      /admin



Everything in /newsletter works just fine. it contains the .asp pages

that *only* disply the data from the database.



Everything in /newsletter/admin/ *edits* the database, ie:

add/remove/edit records. These are the pages that are failing, as the

permissions are wrong.



can I set NT Auth on just the /newsletter/admin pages? 



I need to protect the database, by only letting a select few edit it,

but on the other hand, no one can edit it as it stands now. whats the

best way to do this?



-Kevin



--- Jose Bueno <jbueno@i...> wrote:

> Another solution would be to use NT authentication, period, for the 

> website.  It would mean that your user would have to log in to your

> asp 

> app as well, unless there is a way to share the current login

> information 

> with the session object.

> 

> What that would mean is this

> 

> I go to www.aspapp.com/myapp

> 

> since the myapp application is in a folder that requires a login, I'd

> have 

> to type in my login, password and domain information. Once that's

> done, 

> your login page comes up (because you need to know who is there in

> your 

> app) and the user has to do it again.

> 

> One of the drawbacks to this method is that, aside from having to log

> in 

> twice, your sysadmin has to create these logins as well.  I don't

> know 

> about you, but I don't want the hassles and headaches of having

> outside 

> users with ANY access other than that conferred by IUSER.

> 

> To summarize, segregate your datastore from your presentation layer. 

> Set 

> write permissions only on the folder that ONLY contains the relavent 

> datastores, and restrict the heck out of anything else.  

I'm not a server guy, but as I understand it, NT authentication applies to 

the entire directory structure within the virtual directory specified.  In 

your example, newsletter cannot be IUSER at the same time admin can't be 

KEVIN.



A clarification on your error, please.  Is your database stored in 

newsletter, admin, or anywhere inside the wwwroot directory? 



The pages that actually write data to your database do not need write 

permissions in the directory they are stored in unless the db happens to 

be in the directory with them.  The only directory that IUSER needs write 

access to is the directory where the backend database is stored, and it 

should not be stored in the same directory as your asp pages. Anyway, the 

point I'm trying to make is that you do not want IUSER write permissions 

on any folder inside the wwwroot directory. That's where any scripts that 

can be run would have to be written to.



On my system, I've set c:\webdb as the database storage site.  

c:\...\wwwroot\appname is the web application storage site.  Since IUSER 

(by default) has no rights to C:\ other than to wwwroot and anything 

contained therein, and write permissions is turned off in the IIS 

administrator, nothing malicious can be uploaded unless there is an 

exploit I havent patched.  However, since IIS does have access to that 

local directory, it can read/write to its hearts' content.  Furthermore, 

since c:\webdb is not shared out as a web directory (or shared at all, for 

that matter), any malicious script inserted can't really do a thing other 

than to clutter up the directory... it can't be executed unless you move 

it to wwwroot, and I doubt that will happen.



-Jose