Community
Participate
Working Groups
Remove need to run as administrator with Windows Vista
Here are the findings of Samson's earlier investigations: The AC is currently creating objects (shared memory, named pipes) under the Global name space. Under Vista in order to create any object under the Global name space, Administrator privilege is required. We had a bugzilla opened a few release ago which requires the AC to allow agents started under a different user session to connect. The only way for different sessions to communicate with each other is by using the Global namespace. This solved the multi-session problem but introduced this Vista problem. My proposed solution is to allow the AC to try creating shared memory and named pipes under the Local session if creation under the Global session fails. The user will be notified, possibly by a console warning message and an entry in the log file. Under this mode of operation the AC can only communicate with agents started in the same session. This might have some impact on the agent binding as well since the agent will need to know where to connect. The agent can try connecting to the master named pipe under the Global session first and Local session next. Running AC as Windows service should not be affected since Administrator privilege is required when adding the service. This will be documented as well. This proposal can also be a first step towards allowing multiple AC to be run on the same machine. If the system objects are all created under Local session then AC running under different user sessions will not interfere with each other. This leaves the sockets (10002 - 10006) as the only common resource. Also the solution should be consistant on Linux as well even though there is no notion of Global/Local objects. The "/tmp/IBMRAC" directory can be viewed as a "Global" object in this case. We might create "Local" session on Linux by creating subdirectories under "/tmp/IBMRAC" with user names as session names. Please provide any comment. Thanks.
Harm's input on the initial proposal: Some assumptions here are a bit off, and let's not get into multiple ACs on one machine right now. You may need to have admin authority to install a service, but it can run under various user profiles/levels. So the service scenario is not different. Most real customers we have today do not want or allow the RemoteAC to be at the admin level. Requiring the workbench to be running at the admin level is equally problematic. Do things have to be in the same session or do they have to be in the same user group (access level)? If it is user group then the problem is less serious. As I understand it, this has no effect on the socket level communications, it is only for the agent to AC communications, and in that case the restriction is only for the attach scenarios and not an AC launched scenario (yet) because we only launch in the context of the AC process/session itself at this time.
From Navid: From what Samson has said, it seems like the launch case is affected as well. Correct me if I'm wrong, Samson. I thought the creation of named pipes and shared memory is independent of the agent being launched or attached to.
From Samson: The creation of the shared memory is the responsibility of the AC. Vista's new security mechanism only prevent creation of Global objects by non-Administrator. Normal user can still access Global objects as long as they are already created. For the agent side, currently there is no difference between launching and attaching since the agent will look for the Global shared memory in either case. Under the proposed scenario, if the shared memory is created under a Local user session in the case of an AC started by a normal user, agents might have problems connecting to it - not because it cannot locate the shared memory (we can change the code to pass the session name as well) but instead caused by Vista's inter-session security. This has to be investigated to see if it is allowed.
From Igor: Just one correction: agents also create shared memory segments to establish data channels.
Added sizing.
Results from Igor's investigation as well as his proposal for consideration: Creating shared memory segments in the Global namespace (current): Only users with admin privileges can create objects in the global name space. Currently, both - AC and agents – need to create shared memory segments, so only admin should launch AC and applications with agents. Creating shared memory segments in the Local namespace: Any user can launch AC and agent applications. Launching scenario works well for the same user or another user in another session. Attaching scenario works well for the same user in the same session only. So, for the “one session use”, objects could be created in Local name space without any restrictions. For a “multi-session use”, objects should be created in the Global name space and AC should be launched by Administrator only. I think we can add a special parameter in the config file to control namespace (Local/Global) and set it to the Local by default. In future releases, shared memory could be substituted by sockets (directly from clients to agents). Currently, to establish data channels, clients open sockets to AC, AC and agent, to communicate with each other, create two simplex shared memory segments and AC binds these three connections together (reads data from one connection and writes to other). Using of sockets only could greatly simplify source code and increase reliability and usability of AC.
From what I have learned and understand, it is more precise to say that a multi session scenario requires a global resource and these can only be created by a service or and admin user session. Single sessions do not require the global resource and can be done by any user. RAC/AC launched processes basically fall into a singles session scenario, and the new IAC is no different. The current code only creates a global resource so the "bug" for launch scenarios is that this is not valid on Vista if the session is not an admin or service 0 session. A proposed fix for this bug is to detect the kind of session and create to appropriate resource type. Launch scenarios in fact don't actually need global resources to work. Attach scenarios require a global resource. This means the session that creates the resource must be a service or admin session. Since apparently either may need to create the resource there is little question about the kind of session they must be in. This is an intentional limit of Vista and in fact Server 2003. The above proposed solution will technically address this scenario as well. However, it is not realistic to require a monitored process to be running as admin. It is more reasonable to require the AC to run as a service if attach support is desired. This means we also need to look into more specific control of who creates the resource and attempt to bring this to be an AC service and not done in the monitored app. Although using sockets has an appeal it simply move the authority issue to firewall management, which has historically been a thing we get push back on from commercial users. We also still have a pending work item to assess the performance impacts on the monitored process with a socket implementation. Historically in high data volume scenarios the socket would block and impact the monitored process speed and resources. It seems the first step toward a solution is to enable the creation of global and local resources. Have I missed something in this summary?
Samson, attaching scenarios not always require a global resource. If AC and profiled application are launched during single session, local resources could be used as well.
Hi Igor. Yes that's true only for the single-session scenario. A generalized solution should be implemented to address the multi-session scenario. I have also found that processes running under different sessions might not have the access right to query the other session's process list. This will cause problems in the current AC's isProcessAlive() implementation since there is not a reliable way of differentiating a terminated process or a inaccessible process under the attach scenario. This may cause an agent to be shown as terminated even though it is still alive. Connections will be terminated in this case since the AC thinks that the agent no longer exist. It seems like the Access Control List has to be modified in order to allow this to work properly. Investigation is underway.
(In reply to comment #10) > Hi Igor. Yes that's true only for the single-session scenario. A generalized > solution should be implemented to address the multi-session scenario. > I have also found that processes running under different sessions might not > have the access right to query the other session's process list. This will > cause problems in the current AC's isProcessAlive() implementation since there > is not a reliable way of differentiating a terminated process or a inaccessible > process under the attach scenario. This may cause an agent to be shown as > terminated even though it is still alive. Connections will be terminated in > this case since the AC thinks that the agent no longer exist. It seems like the > Access Control List has to be modified in order to allow this to work properly. > Investigation is underway. It seems there is a need for multiple bugzilla to track the various fixes. One for the local/global resource issue and now one for this matter. I suspect we will have more at the agent level as we get more function working outside admin.
My testing of the fix shows that the following piAgent profiling scenarios work: - AC(admin) -> Launch - AC(user) -> Launch - AC(admin) -> Attach -> Agent(admin) - AC(admin) -> Attach -> Agent(user) - AC(user) -> Attach -> Agent(user) "admin" = started as Administrator "user" = started as normal non-administrative user The only non-working scenario is when AC is started as normal user and the agent is started from another session, whether admin or not. This is because the agent cannot locate the shared memory under both "Global" and "Local" namespace.
*** Bug 170572 has been marked as a duplicate of this bug. ***
Fix checked into CVS 2007/04/10 11:52 EDT.
Update sizing.
closing
