pause system functionality until my python script is done - python

I have written a simple python script that runs as soon as a certain user on my linux system logs in. It ask's for a password... however the problem is they just exit out of the terminal or minimize it and continue using the computer. So basically it is a password authentication script. So what I am curious about is how to make the python script stay up and not let them exit or do anything else until they entered the correct password. Is there some module I need to import or some command that can pause the system functions until my python script is done?
Thanks
I am doing it just out of interest and I know a lot could go wrong but I think it would be a fun thing to do. It can even protect 1 specific system process. I am just curious how to pause the system and make the user do the python script before anything else.


There will always be a way for the user to get past your script.
Let's assume for a moment that you actually manage to block the X-server, without blocking input to your program (so the user can still enter the password). The user could just alt-f1 out of the X-server to a console and kill "your weird app". If you manage to block that too he could ssh to the box and kill your app.
There is most certainly no generic way to do something like this; this is what the login commands for the console and the session managers (like gdm) for the graphical display are for: they require a user to enter his password before giving him some form of interactive session. After that, why would you want yet another password to do the same thing? the system is designed to not let users use it without a password (or another form of authentication), but there is no API to let programs block the system whenever they feel like it.


You want the equivalent of a "modal" window, but this is not (directly) possible in a multiuser, multitasking environment.
The next best thing is to prevent the user from accessing the system. For example, if you create an invisible window as large as the display, that will intercept any mouse events, and whatever is "behind" will be unaccessible.
At that point you have the problem of preventing the user from using the keyboard to terminate the application, or to switch to another application, or to another virtual console (this last is maybe the most difficult). So you need to access and lock the keyboard, not only the "standard" keyboard but the low-level keys as well.
And to do this, your application needs to have administrative rights, and yet run in the user environment. Which starts to look like a recipe for disaster, unless you really know what you are doing.
What you want to do should be done through a Pluggable Authentication Module (PAM) that will integrate with your display manager. Maybe, you can find some PAM module that will "outsource" or "callback" some external program, i.e., your Python script.


Since this thing is just for fun, here's a work arond: make the script log the user out if he ignores the prompt for some time, or closes the terminal/kills the process. Here's how it might look like for gnome:
import os
def set_exit_handler(func):
import signal
signal.signal(signal.SIGHUP, func) # on closing the terminal
signal.signal(signal.SIGTERM, func) # on killing the process
import atexit
atexit.register(func) # on Ctrl-C, Ctrl-D and other proper exits
if __name__ == "__main__":
def on_exit(a=None, b=None):
print "exit handler triggered"
os.system("gnome-session-quit --logout --no-prompt")
set_exit_handler(on_exit)
print "Enter password:"
raw_input()
# ... some verification/timeout code ...
If the user will now close the terminal or kill the process, he'll be logged out instantaneously :)

Related

running a python script from startup to shutdown

I am using python 3. On windows 7.
I recently made a python keylogger. It saves the keylogs in a text file as i type and upon pressing WIDOWS Key it sends the text from the textfile to my gmail account using smtplib.
I have to manually start the python file and it gets quite boring!
What my question is that is there any way to run that keylogger script on startup (without manually putting it in the startup folder -- because i want the script to do everything itself), and then to quickly close the script as soon as the user presses the shutdown button (and delay the shutdown time somehow).
The reason i want this is because i belive that a keylogger must be hidden from the user not to include that it must be hidden from the antivirus ;)
i have tested this with python task scheduler but it only takes time parameters (i.e. from 5:00 to 7:00) not the startup and shutdown time.
If i am to include more information on this topic that you need to solve this question i will gladly help you!
Thanks in advance

how to use lldb trace-thread and python SBThread eBroadcastBitSelectedFrameChanged event

I want to trace thread by log all the symbol it call, so I found tow method
1、the lldb settings list:
'target.process.thread' variables:
trace-thread -- If true, this thread will single-step and log execution.
it means the lldb will log execution, but I can't find where is the log
2、lldb python SBThread has a event eBroadcastBitSelectedFrameChanged, I think it will callback when thread frame change, but why SBThread has no broadcaster?

1) This setting was put in mostly to help diagnose problems with lldb's stepping algorithms. Since it causes all execution to go by instruction single step, it's going to make your program execute very slowly, so it hasn't been used for anything other than that purpose (and I haven't used it for that purpose in a good while, so it might have bit-rotted.) The output is supposed to go to the debugger's stdout.
2) eBroadcastBitSelectedFrameChanged is only sent when the user changes the selected frame with command line commands. It's meant to allow a GUI like Xcode that also allows command line interaction to keep the GUI sync'ed with user commands in the console. There isn't a GetBroadcaster for threads, because threads come and go and you generally want to listen to ALL the threads, not just a particular one. To do that, call SBThread.GetBroadcasterClassName and then sign your listener up for events by class name (StartListeningForEventClass).
If you have a need to listen to a particular thread, file an enhancement request to the bug tracker at http://lldb.llvm.org.

Zenity not working in python script with crontab

I have a python script in which I have used Zenity to display some notification. The code snippet is as follows:
if message_list:
pretty_print(message_list)
os.system("/usr/bin/zenity --notification --text='You have unread messages'")
When I run this script normally, everything works fine i.e. dialog box appears and message gets displayed. But when I schedule this script in crontab nothing appears. Any solution to this?

There is no sane way to run interactive commands from cron. There is no guarantee that there is a user, there is no guarantee that there is a single user, there is no guarantee that the user(s) who are on want to, or are even able to, interact with your software; some of them may be pseudo-users or remote on expensive metered Internet access or just idle or whatever.
The usual solution is a server/client architecture where whatever runs from cron makes its results available via some IPC mechanism, and users who want the results run a client from within their X11 session (or shell, or what have you).

Create a script info.sh (remember to grant it execute rights):
#!/bin/bash
xhost +
/usr/bin/zenity --notification --text='You have unread messages'
And in your script:
if message_list:
pretty_print(message_list)
os.system("./info.sh")
That's if you want to use the solution you mentioned.

Registry handles leaked?

We're running a Python script (which uses multithreading) to do some work on an Amazon-EC2 based Windows Server 2008 machine. When the machine starts, I can see that it starts executing the Python script, and then I start seeing messages like the following in the event log:
Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.
DETAIL -
19 user registry handles leaked from \Registry\User\S-1-5-21-2812493808-1934077838-3320662659-500_Classes:
Process 2872 (\Device\HarddiskVolume1\Python27\python.exe) has opened key \REGISTRY\USER\S-1-5-21-2812493808-1934077838-3320662659-500_CLASSES
Process 2844 (\Device\HarddiskVolume1\Python27\python.exe) has opened key \REGISTRY\USER\S-1-5-21-2812493808-1934077838-3320662659-500_CLASSES
Process 2408 (\Device\HarddiskVolume1\Python27\python.exe) has opened key \REGISTRY\USER\S-1-5-21-2812493808-1934077838-3320662659-500_CLASSES
What exactly does this mean, and how do I stop Windows from killing some of the threads?

When a scheduled task is configured to run as a particular user, that user's account is logged on non-interactively in order to run the task. When the task is finished, the user's registry hive is unloaded. For some reason, this is happening prematurely.
From your description, you have a single scheduled task, which launches various subprocesses. It seems likely that the parent process is exiting before the subprocesses are finished, and that this is causing the user's registry hive to be unloaded. You can verify this theory by turning on auditing for process creation and termination (in Group Policy under Advanced Audit Policy Configuration) or by using a tool such as Process Monitor (available from the MS website).
Assuming this is the cause, the fix is for the parent process to wait for the subprocesses to exit before itself exiting; alternatively, depending on your circumstances, it may be sensible for the parent task to simply never exit.
If you don't have direct control over the relationship between the parent process and the subprocesses then you'll need to create a new parent process to launch the script for you, and then either wait for all subprocesses to complete or sleep forever, as appropriate.

It may be that some your files are corrupted. Try the following:
Perform SFC(System file Checker) scan and see if it helps.
Press Windows key + X.
Select Command Prompt(Admin).
Type sfc /scannow and hit enter.
Also perform a chkdsk:
Press Windows Logo + C to open the Charms bar.
Now click Settings and then More PC Settings.
Now click General and then click Restart Now under Advanced Startup.
Now Click Troubleshoot.
Now click Advanced options and select Command prompt.
Type chkdsk /r and hit enter.
Last but not least, if the above doesn't work, you can perform a startup repair:
Press Windows logo + W to open the search box.
Type Advanced Startup options, hit enter.
Then Click Restart Now under Advanced Startup.
Now Click Troubleshoot.
Then click Advanced options and then Automatic Repair.
Hope it helps.

Is there something between a normal user account and root?

I'm developing an application that manages network interfaces on behalf of the user and it calls out to several external programs (such as ifconfig) that requires root to make changes. (Specifically, changing the IP address of a local interface, etc.) During development, I have been running the IDE as root (ugh) and the debugger as root (double-ugh). Is there a nice way for the end-user to run these under a non-root account? I strongly dislike the size of the attack surface presented by GTK, wxPython, Python, and my application when it runs as root.
I have looked into capabilities, but they look half-baked and I'm not sure if I'd be able to use them in Python, especially if they are on a thread basis. The only option I haven't explored is a daemon that has the setuid bit set and does all the root-type stuff on behalf of the UI. I'm hesitant to introduce that complexity this early in the project, as running as root is not a dealbreaker for the users.

Your idea about the daemon has much merit, despite the complexity it introduces. As long as the actions don't require some user interface interaction as root, a daemon allows you to control what operations are allowed and disallowed.
However, you can use SUDO to create a controlled compromise between ROOT and normal users... simply grant SUDO access to the users in question for the specific tools they need. That reduces the attack surface by allowing only "permitted" root launches.

What you want is a "Group"
You create a group, specify that the account wanting to do the action belongs to the group, then you specify that the resource you want access to is a member of that group.
Sometimes group management can be kind of irritating, but it should allow you to do anything you want, and it's the user that is authorized, not your program.
(If you want your program authorized, you can create a specific user to run it as and give that user the proper group membership, then su to that group within your program to execute the operation without giving the running user the ability.)

You could create and distribute a selinux policy for your application. Selinux allows the kind of fine-grained access that you need. If you can't or won't use selinux, then the daemon is the way to go.

I would not run the application full time as root, but you might want to explore making your application setuid root, or setuid to some id that can become root using something like sudo for particular applications. You might be able to set up an account that cannot login, use setuid to change your program's id (temporarily when needed) and have sudo set up to not prompt for password, but always allow access to that account for specific tasks.
This way your program has no special privileges when running normally, only elevates it's privileges when needed, and is restricted by sudo to only running certain programs.
It's been awhile since I've done much Unix development, so I'm not really sure whether it's possible to set up sudo to not prompt for a password (or even if there is an API for it), but as a fallback you could enable setuid to root only when needed.
[EDIT] Looks like sudo has a NOPASSWD mode so I think it should work since you're running the programs as external commands.

The traditional way would be to create and use a setuid helper to do whatever you need. Note that, however, properly writing a setuid helper is tricky (there are several attack vectors you have to protect against).
The modern way would be to use a daemon (running as root, started on boot) which listens to requests from the rest of the application. This way, your attack surface is mostly limited to whichever IPC you chose (I'd suggest d-bus, which seems to be the modern way).
Finally, if you are managing network interfaces, what you doing is very similar to what network-manager does on a modern distribution. It would be a good idea to either try to somehow integrate what you are doing with network-manager (so it will not conflict with your manipulations), or at least looks at how it works.

There's no single user that is halfway between a "normal" user and root. You have root, and then you have users; users can have differing levels of capabilities. If you want something that's more powerful than a "normal" user but not as powerful as root, you just create a new user with the capabilities you want, but don't give it the privileges you don't want it to have.

I'm not familiar enough with Python to tell you what the necessary commands would be in that language, but you should be able to accomplish this by forking and using a pipe to communicate between the parent and child processes. Something along the lines of:
Run the program as root via sudo or suid
On startup, the program immediately forks and establishes a pipe for communication between the parent and child processes
The child process retains root power, but just sits there waiting for input from the pipe
The parent process drops root (changes its uid back to that of the user running it), then displays the GUI, interacts with the user, and handles all operations which are available to a non-privileged user
When an operation is to be performed which requires root privileges, the (non-root) parent process sends a command down the pipe to the (root) child process which executes it and optionally reports back to the parent
This is likely to be a bit easier to write than an independent daemon, as well as more convenient to run (since you don't need to worry about whether the daemon is running or not), while also allowing the GUI and other things which don't need root powers to be run as non-root.

Categories

Resources