Folder Permissions

[David]

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?

Thanks
David

 

[Roger Abell [MVP]]

"David" <dw85745NOT@earthlink.net> wrote in message
news:%23pfO3HFEJHA.5732@TK2MSFTNGP04.phx.gbl...
> 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

 

[David]

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
server and myself (client), the server may execute a function(s) within the
DLL unknown to the client -- hopefully not!

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.

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

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
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)
5) Set user logon and folder permissions to read and execute

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


"Roger Abell [MVP]" <mvpnospam@asu.edu> wrote in message
news:ePmNbSMEJHA.1268@TK2MSFTNGP05.phx.gbl...
> "David" <dw85745NOT@earthlink.net> wrote in message
> news:%23pfO3HFEJHA.5732@TK2MSFTNGP04.phx.gbl...
>> 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
>

 

[Roger Abell [MVP]]

"David" <dw85745NOT@earthlink.net> wrote in message
news:u50ZjFPEJHA.4304@TK2MSFTNGP02.phx.gbl...
> 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@asu.edu> wrote in message
> news:ePmNbSMEJHA.1268@TK2MSFTNGP05.phx.gbl...
>> "David" <dw85745NOT@earthlink.net> wrote in message
>> news:%23pfO3HFEJHA.5732@TK2MSFTNGP04.phx.gbl...
>>> 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
>>
>
>

 

[David]

Thanks for response Roger.

> 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

Good point Proxy is best guess as once link is established with server it
is continuous until terminated.
Periodic calls are then made with callbacks from the server. Whether
server can independently
make callbacks or remote manipulate is unknown -- this is krux of my
concern.

>What I was saying is that your exe runs as the account that starts it.

I believe your above statement says it all.
Hopefully I can get the permissions right as no way to really test.



"Roger Abell [MVP]" <mvpnospam@asu.edu> wrote in message
news:ukvay1XEJHA.1456@TK2MSFTNGP03.phx.gbl...
> "David" <dw85745NOT@earthlink.net> wrote in message
> news:u50ZjFPEJHA.4304@TK2MSFTNGP02.phx.gbl...
>> 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@asu.edu> wrote in message
>> news:ePmNbSMEJHA.1268@TK2MSFTNGP05.phx.gbl...
>>> "David" <dw85745NOT@earthlink.net> wrote in message
>>> news:%23pfO3HFEJHA.5732@TK2MSFTNGP04.phx.gbl...
>>>> 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
>>>
>>
>>
>
>