Re: Interface-based security?
- From: "Alexander Nickolov" <agnickolov@xxxxxxxx>
- Date: Wed, 23 Aug 2006 10:14:26 -0700
You can use programmatic security. Construct a security
descriptor that allows access to Everyone and denies access
to the Network Users standard group. Then use the server
security interface IServerSecurity (via CoGetCallContext) to
impersonate the caller via IServerSecurity::ImpersonateClient.
Perform an AccessCheck() against your manually crafted
security descriptor. It will pass for all local callers and fail for
all network callers. Finally, call IServerSecurity::RevertToSelf.
You need this check called upon entry from each interface
method on the restricted interface, _except_ for the IUnknown
methods (!).
Here's a list of security functions you'd use to construct your
security descriptor:
InitializeAcl
CreateWellKnownSid (WinNetworkSid and WinWorldSid)
AddAccessDeniedAce
AddAccessAllowedAce
InitializeSecurityDescriptor
SetSecurityDescriptorDacl
Note that WinLocalSid alone won't fit the bill since it matches all
local accounts regardless of whether they are logged in locally
or remotely. It also excludes domain accounts logged locally.
You could use it in place of WinWorldSid if you specifically
want to exclude domain accounts even locally.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"jesse" <jessegarbage@xxxxxxxxx> wrote in message
news:1156347282.719263.321490@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I want to create a DCOM server that allows some users to call certain
methods, and other users to call other methods. I will settle for a
compromise or workaround, but I'd like to know what others would do
here. Here's the situation:
I have a COM object hosted in a service. It serves as a database--the
client applications need to access about 40 GB of data at random, speed
is of the essence. The service runs on a box that has over 100 GB of
memory, so this works. The com object uses the
DECLARE_CLASSFACTORY_SINGLETON() macro, so all clients are talking to
the same instance. One client modifies/writes data, other clients only
read data. The object serves the client applications perfectly. Since
this all runs on a secure machine, remote access is disabled in DCOM
config, and that's that.
This has all been working perfectly until now. Now I need other
machines to be able to read data from this server. Ideally, I'd like
to break off methods like WriteData() into a separate interface, called
IDataWriter and have that interface not accessible from the remote
clients.
I've considered overriding QueryInterface and return E_FAIL if the
client is remote, but I don't know how to determine if it's remote or
local. Also, I'm not sure if this is a safe approach.
Any suggestions?
TIA,
Jesse
.
- References:
- Interface-based security?
- From: jesse
- Interface-based security?
- Prev by Date: Re: Interface-based security?
- Next by Date: Re: proper way of handling [out,retval] VARIANT * args
- Previous by thread: Re: Interface-based security?
- Next by thread: proper way of handling [out,retval] VARIANT * args
- Index(es):
Relevant Pages
|
