Re: Folder Permissions



"David" <dw85745NOT@xxxxxxxxxxxxx> wrote in message
news:u50ZjFPEJHA.4304@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for response Roger, but I need more specifics.

A dll may contain many used and unused functions. Hence who knows what
may reside in any DLL. Since a direct internet link is maintained between
the

There is a difference between a network link existing and a session or
connection being used over that network link.
What I am not clear about is whether your exe (which uses this dll) makes
a call for something to happen on the server and then the call is complete
(i.e. execution is totally synchronous) or whether you make a call which
then sets up a proxy for a process that is started up on the server and from
that point on the server can make call backs to your proxy (i.e. your code
would need to either start a thread for the call or it would make the call
and wait until the proxy gets torn down). Even in the case where the
server can make call backs, that does not mean that the proxy or calling
thread will execute whatever the server tell it to do - it may only accept
data in return, right?

server and myself (client), the server may execute a function(s) within
the DLL unknown to the client -- hopefully not!


Depends on the architecture, per above for example.
If I make a call and it sends 2,2 over to the server, and the server does a
2+2 and sends back 4 and that is it, connection done, then it is not likely
that the server will be repeatedly sending anything to the caller.
On the other hand, the server and client could keep the connection open
and repeately send number pairs over and get a result back.
What you seen concerned with is that once a persistent connection is set
up, then the server will be telling the client to use this method or that an
transfer the results back. That is a possibility, but it is possibly the
most
sophisticated case of those mentioned. You need to know the code.

My understanding of NTFS is the design is to keep people from getting into
folders not out of them. Hence the orientation is based on user logon
into say my machine and then accessing a folder based on rights given to
the user at logon.


That sounds like two sides of a single coin to me.
What I was saying is that your exe runs as the account that starts it.
What the exe does very likely will run in that same context (only likely as
it is possible with COM or NetFx to do otherwise).
Hence, if that account has no access elsewhere, i.e. it cannot get into
those
folders you are concerned over, the server could not use call back to cause
your exe to expose info about those folders' content. An access denial
would
be the result of such an attempt.


=====================

This is where "I Think" I'm confused.

If a DLL resides in c:\windows\system, that directory normally is a
general folder where most DLLs resides. Since I am the user of the
program (also administrator and normally logon as such), will the
following solve any potential DLL problems?:

1) Creation of a separate user account

Yes. That is what I have been saying. Run the exe only
with an account with tightly controlled grants as to where
it is allowed.

2) Create a folder under this account
3) Move my program to the new folder under the new account
4) Move the supplied DLL to the new folder under the new account and
register it there (if possible)
should be possible
5) Set user logon and folder permissions to read and execute


2 is not relevant, rather an admin acocunt could make the new folder
and set up the grants.
3-5 might help, but since the account that runs the exe (limited account
defined per your item 1) must log in to run it, that usually means the
account needs to be a member of the Users group, which means it has
grants on the system folder in order to log in.
Hence 3-5 would be more of use in making users other than the account
defined (per your item 1) unable to run the exe or use the dll.


What if the DLL must reside in c\windows\system?


not likely, something would have to be hard coded in the dll for force that

anyway, moving it from the system dir is something one would do to
prevent other users from having a grant on it


"Roger Abell [MVP]" <mvpnospam@xxxxxxx> wrote in message
news:ePmNbSMEJHA.1268@xxxxxxxxxxxxxxxxxxxxxxx
"David" <dw85745NOT@xxxxxxxxxxxxx> wrote in message
news:%23pfO3HFEJHA.5732@xxxxxxxxxxxxxxxxxxxxxxx
Confused -- Newbie to Permissions!!!!!

1) Sole owner and Admin of XP-Pro Machine.

2) I have a DLL incorporated into a program ("exe") I've written. This
"exe" maintains a real-time link to a server. Other than seeing the
function headers I don't what resides in the server provided DLL.

3) DLL is currently registered in c:\Windows\System

4) I would like to keep someone from the server side from accessing
other folders on my machine.

QUESTIONS:

How do I go about this?

a) Move and Register the DLL in the "exe" folder?
b) Set permissions on the "exe" folder or do all higher folders
need to have permissions set?
c) What are the recommended permissions settings for this?
d) Is encryption needed?


David

There are many, mnay unknowns left unanswered by what you have said.
You wrote the exe, so you control what methods of the dll are called.
Evidently you do not know what the methods do, at least not fully, so you
do not have trust about what happens when exection has been transferred
to the dll, and you have only said that a connection if maintained
between
the XP where your exe is running and some server.

A general answer to your scenario would go at this by controlling the
account the runs your exe, and hence is the security context in which the
methods of the dll will execute. If that account has no permissions
other
than what is needed to run your exe, no permissions on extra areas of
your
XP machine, then you know exactly what might be accessed. That however
is not always easy to do, since the account evidently needs to be able to
log
on locally in order to run the exe.

Roger





.



Relevant Pages

  • Re: Using same interfaces for in-proc vs. out-proc
    ... for each server) might work better after all. ... TLB,>you reference it in VB and gain access to all ... both EXE and DLL versions must use the same source code; ...
    (microsoft.public.vc.atl)
  • Many, many thanks
    ... Assuming that you instantiate the object in the dll on a .asp page, ... if you want to keep a dll loaded in IIS you have a couple ... my ole server dll was exposed. ...
    (microsoft.public.inetserver.iis)
  • Re: DShowNET - create instance of Clsid.FilterGraph fails?
    ... I don't know how much you know about COM, but a CLSID is usually associated ... with a DLL or exe which acts as a COM server once it is called properly. ... This DLL or exe is installed on your machine (unless you are using DCOM, ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: Difference between an EXE and DLL ATL objects
    ... If accessing EXE COM methods has all this overhead ... DLL server, whereas one EXE server may serve multiple clients. ...
    (microsoft.public.vc.atl)
  • Re: ROT Vs Out of Proc COM Server
    ... in a DLL instead of an EXE? ... Once the DLL is loaded, ... > name, i retrieved its interface pointer from another exe, and it works ... >> in a inproc server, use a dummy exe to CoCreate its instance, push its ...
    (microsoft.public.win32.programmer.ole)