How to make an Agent work in the system session? - macos

I'm trying to a background program that need to connect to window server, which is not allowed in a daemon. But may job is quite appropriate to be done in [System] session which daemons act.
I have tried to set session of the Agent.(Aqua by default)
LimitLoadToSessionType: System
But it didn't work.. Is it wrong? How can I do it?

May be [LoginWindow] + [Aqua] could match the right session. But between the two session, the program need to be shutdown and relaunched.

Related

How to check if session is being shadowed in Windows Terminal Server

Assume the following scenario:
I log on terminal server with RDP (Windows Server 2012 R2 or 2016)
Another user connects to my session with "mstsc.exe /shadow" command.
I get the message to confirm this access, and I agree.
Then, after a while I would like to check if my session still being shadowed.
Is there any way to perform this check? Any command, Win32 API, WMI query?
So far, I was only able to find out that rdpsaproxy.exe program is started in shadowed session. That is almost enough, but this program also keeps running when user denies access when prompted to accept initial shadowing request. So detecting presence of rdpsaproxy in check session is not enough to say that somebody is watching me.
You could bind a notification task to the events of Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational event log:
20503 - shadow watching started
20504 - shadow watching stopped
20506 - shadow control started
20507 - shadow control stopped

How to Prevent User From Closing Putty Session while a job is running

So we are using Putty to connect to our server. Sometime when a user is running a job, they would have to wait for the job to be done before they can close the session. If they close the session before the job is done, it would corrupted. I wonder is there anyway we can stop the user from closing the session when something is running.
No, there is not. Tell your clients to use the screen command. This will create a separate session, then you run the long-running command (batch, ...). If you're disconnected, you just have to run screen -r to reconnect.

How do I secure a per user GUI launchd agent against a non admin user disabling it?

I have a pair of launchd daemons, one of which is a true daemon (runs as root) and one of which is a GUI agent that runs as a per GUI session basis (session type Aqua).
I need to prevent non admin level users from disabling the user level agent using launchctl, or at the very least figure out how to reload the agent from the root level daemon.
The best article I've found so far is this one, but it doesn't really offer any clear solutions.
The easiest way would seem to be to fetch the current console user periodically in the root daemon and then run launchctl load ... as that user, but I'm not entirely if if that's possible/how I would go about this (if I just run load from the daemon without posing as the user, it will be loaded under the root user, which does no good).
Any ideas?
you could check for authorization in your SIGTERM handler, see http://developer.apple.com/mac/library/technotes/tn2002/tn2095.html for sample custom authorization check

Killing an Oracle job. 10g specific

We're using a job scheduling system that runs on top of DBMS_JOB. It uses a master job to create one-time jobs. We deploy the same set of jobs to all our clients, but can specify which jobs should only run at certain clients.
We get occasional problems with a process run by a job hanging. The main cause of this is UTL_TCP not timing out when it does get an expected response. I want to be able to kill those jobs so that they can run again.
I'm looking at creating a new job that kill any of these one-time jobs that have been running for longer than a certain time.
We're stuck with Oracle 10g for a while yet, so I'm limited to what that can do.
There's an article that seems to cover most of this at
http://it.toolbox.com/blogs/database-solutions/killing-the-oracle-dbms_job-6498
I have a feeling that this is not going to cover all eventualities, including:
We run can jobs as several different users and a user can only break/remove jobs they created. I believe that I may be able to use DBMS_IJOB to get around that, but I need to get the DBA to let me execute it.
We have Oracle RAC systems. I understand 10g limits ALTER SYSTEM KILL SESSION to killing sessions on the current instance. I could arrange for all jobs to run on the same instance, but I've not tried that yet.
Anything else I should consider? Stack Overflow needs a definitive answer on this.
You can get the PID from the job tables and kill the stuck process via the normal OS commands.
You can kill jobs on any instance. On 10g, you need to know on which instance the stuck job is running, and connect to that instance:
To get your instance and pid:
select inst_id, process from gv$session where ...
Connect to a specific instance:
sqplus admin#node3 as sysdba
alter system kill session ...
There are more ways to kill a session on oracle. Depends on your plattform. Running on unix sessions (background jobs too) are represented by processes. Killing the process, kills the session. On windows sessions are represented by a thread. Killing the thread using orakill, kills the session. The process (or thread) id is stored in gv$process.

On Terminal Server, how does a service start a process in a user's session?

From a Windows Service running on a Terminal Server (in global space), we would like to be able to start up a process running a windows application in a specific user's Terminal Server sessions.
How does one go about doing this?
The Scenerio: the windows service starts at boot time. After the user has logged into a Terminal Server user session, based on some criteria known only to the windows service, the windows service wants to start a process in the user's session running a windows application.
An example: We would like to display a 'Shutdown in 5 minutes' warning to the users. The windows service would detect this condition, and start up a process in each user session that starts the windows app that displays the warning. And, yes, I know there are other ways of displaying a warning dialog, this is the example, what we want to do is much more invasive.
You can use CreateProcessAsUser to do this - but it requires a bit of effort. I believe the following steps are the basic required procedure:
Get the user's session (WTSQuerySessionInformation).
Get a token for that user (WTSQueryUserToken).
Create a duplicate token for your use (DuplicateTokenEx).
Use the token to create an environment block (CreateEnvironmentBlock).
Launch the application with CreateProcessAsUser, using the block above.
You'll also want to make sure to clean up all of the appropriate handles, tokens, etc., after you've launched the process.
Really late reply but maybe somebody will find this helpful.
You can use PsExec to launch an application on a remote (or local) server inside a specified session by using the following command:
psexec \\COMPUTER_NAME -i SESSION_ID APPLICATION_NAME
Where SESSION_ID indicates the session id in which to launch the application.
You will need to know what sessions are active on the server and which session id maps to which user login. The following thread provides a nice code sample for this exact problem: How do you retrieve a list of logged-in/connected users in .NET?
Late reply but in the answer above DuplicateToken is not necessary since WTSQueryUserToken already returns a primary token.

Resources