I am interested in stopping all processes other than the one I am writing from printing to the tty in which my process is running. It can be assumed that my application is only to be ran in a real tty.
I would prefer a POSIX compliant solution, but ubuntu or freeBSD specific solutions would be appreciated as well. The system I am coding on is Ubuntu 14.
I am writing in C, but portability is not so much of a concern that I would need to avoid system calls, nonstandard headers (like POSIX headers), etc.
I am having a hard time seeing where to start with this. I thought maybe stty would have a command for it, but I couldn't find one in its man page.
To illustrate my issue, my application uses the terminal as a character grid rather than a sequence of lines, so when a keyboard is plugged in, I get output regarding configuration, which overwrites the characters I have in place. I am about to resort to regular reprinting of the entire screen, but I'd really like to avoid that. So, to do that, I really need to stop other processes from writing to the tty.
Thanks in advance!
Related
I have made a decent console application in C. The issue is that arrow keys print an escape sequence to the input instead of moving the cursor or navigating previous input. On Windows it works well (same behavior of command prompt).
How can I pull the same thing on Linux?
The C++ programming language is made to be a very efficient language. As such, the language itself (i.e. without including any libraries) can't really do that much, basically you can only get input through argc and argv and you can only send output through the return value.
The standard library helps a lot, giving us access things such as files, allowing us to do a lot more. As console developers it also allows us to use the standard input and the standard output through std::cin and std::cout (also the standard error stream through std::cerr but we usually hope nothing will be written to it). Since we get access to those tools through streams, to our program there's no such thing as "The second line from the top of the console", it's only a long line of letters. As such it's absolutely impossible to do this using only C++ and the standard library.
What about windows then? It can do it! Yes, but that's a windows thing, not a C++ thing (it's being a while since I used windows but I remember it sometimes causing issues with streams), third-parties windows-compatible console emulators can function exactly like Linux terminals (and I guess Linux terminals could work just like windows, I just haven't seen one yet) so we need something to guaranty us this behavior.
Thankfully, one of the main advantage of C/C++ is the sheer number of libraries available to us. An big part of C++ programs don't even use a console anymore, bypassing completely the issue.
What I'd recommend is to find a good library (I sometimes use ncurses although I think it's Linux-only and probably a bit too feature full for your usecase) and use it to control the cursor to make it do what you want
I want to write software that will detect all used/created/modified/deleted files during the execution of a process (and its child processes). The process has not yet run - the user provides a command line which will later be subprocessed via bash, so we can do things before and after execution, and control the environment the command is run in.
I have thought of four methods so far that could be useful:
Parse the command line to identify files and directories mentioned. Assume all files explicitly mentioned are used. Check directories before/after for created/deleted files. MD5 existing files before/after to see any are modified. This works on all operating systems and environments, but obviously has serious limitations (doesnt work when command is "./script.sh")
Run the process via another process like strace (dtruss for OSX, and there are equivalent windows programs), which listens for system calls. Parse output file to find files used/modified/deleted/created. Pros that its more sensitive than MD5 method and can deal with script.sh. Cons that its very OS specific (dtruss requires root privileges even if the process being run does not - outputs of tools all different). Could also create huge log files if there are a lot of read/write operations, and will certainly slow things down.
Integrate something similar to the above into the kernel. Obviously still OS specific, but at least now we are calling the shots, creating common output format for all OS's. Wouldn't create huge log files, and could even stop hooking syscalls to, say, read() after process has requested the first read() to the file. I think this is what the tool inotify is doing, but im not familiar with it at all, nor kernel programming!
Run the process using the LD_PRELOAD trick (called DYLD_INSERT_LIBRARIES on OSX, not sure if it exists in Windows) which basically overwrites any call to open() by the process with our own version of open() which logs what we're opening. Same for write, read, etc. It's very simple to do, and very performant since you're essentially teaching the process to log itself. The downside is that it only works for dynamically-linked process, and i have no idea of the prevalence of dynamic/statically linked programs. I dont even know if it is possible before execution to tell if a process is dynamically or statically linked (with the intention of using this method by default, but falling back to a less-performant method if its not possible).
I need help choosing the optimal path to go down. I have already implemented the first method because it was simple and gave me a way to work on the logging backend (http://ac.gt/log) but really i need to upgrade to one of the other methods. Your advice would be invaluable :)
Take a look to the source code of "strace" (and its -f to trace children). It does basically what you are trying to do. It captures all the system calls of the process (or its childs) so you can grep for operations like "open", etc.
The following link provides some examples of implementing your own strace by using the ptrace system call:
https://blog.nelhage.com/2010/08/write-yourself-an-strace-in-70-lines-of-code/
Are there any limitations using a C 'shell emulator' in this way for a user to send commands to the kernel (in linux)? As an afterthought question, if you set a user to not have shell access, what stops them using something like this to interact with the kernel? (by say running the program from shell_exec via php)?
(by restricting the user, I mean in /etc/passwd)
Thanks
Okay, there are several issues here.
First off, popen isn't terrifically satisfactory as a way to emulate a shell, because you won't be able to create your own pipelines and you'll constantly be fighting permissions and things like that.
Second, popen doesn't protect you particularly against malicious commands anyway.
What you really want is to use a restricted shell.
Update
In answer to your second question, pretty much nothing. Which is why you should use that with great care.
I am working on an embedded project, where I need a program without external dependencies that works like screen or tmux. These two programs are not good because they need other libraries.
Since I only need to detach a program, being able to log-out and getting it back when I log-in again, I was wondering whether I can write a small program for that.
Do you know which calls (in C) I need to do to detach the program and to have it back?
If i understand your requirements correctly, you could theoretically use termios struct and ioctl to achieve this.
ioctl(0, TIOCNOTTY, NULL);
to detach and
ioctl(0, TIOCSCTTY, 1);
to attach back to the terminal. However, it doesn't actually perform the job.
The following solution describes a not so nice but practical work around
tty demulsified
The primary intention there is to attach program to another terminal but i believe that is the way you can achieve your goal too.
Regarding your mention of embedded platform, you might be able to find some help from busybox
It compiles for embedded linux with a pretty small binary and contains most of commonly used linux utilities such as getty, stty etc.
I'm current supporting some legacy software written aeon ago, compiled in gcc 2.95.3. The program is ran in an SBC, occasionally I had to telnet into it to fix things. I notice that when the SBC is running on its own, it display some unexpected behavior e.g. missed executions.
When I do telnet in, slay the process and execute it manually, it stays fine that way. I'm suspecting that this has to do with performing printf without a proper terminal/console for it to print on.
If printf are not handled, what would be the effect of it?
Could it be that the system is trying to print to a hardware serial port (which are really slow) and when you telnet in its replaced by a TCP port instead?
It depends on the stdio library you use, most will attempt to write to console anyway, so...
You should redirecting your STDOUT and STDERR to NULL or to a file, this should be quiet easy.
gcc 2.95 was very stable so we can pretty much rule out any problems there.