I need to run a single curl command. The powers that be have decided this has to be done in C to avoid anyone being able to see the source code.
I don't know anything about C and have only little programming experience but I found you can use system() to execute a shell command like this:
int main()
{
system("/usr/bin/curl http://192.168.1.1");
return 0;
}
However, will there be a record/log anywhere in Linux (Ubuntu) that shows the full command my program executed?
Anyone with access to your account will easily find out whatever you are trying to hide (using strings or strace).
Someone without said access (hopefully the whole world except you and your sysadmin) can still use ps. It won't make any difference whether you use a C wrapper or run the command directly: in both cases ps will show the command and its arguments in all their glory.
Some commands, like sqlplus, manipulate their command line immediately after (although not exactly at) startup to hide e.g. password from prying eyes. curl does the same with usernames and passwords, but certainly not with URLs (which can be easily spied upon by network monitoring tools anyway)
On (post-3.2) linux, your sysadmin can (re-)mount /proc such that only root has access to your command lines, using the hidepid mount option
This will go a long way towards protecting your command lines - a C wrapper will only be useful for its placebo effect on your boss.
I need to run a single curl command. The powers that be have decided this has to be done in C to avoid anyone being able to see the source code.
You probably need to make a single HTTP request. I recommend taking time to read some HTTP specification, like RFC 2616 or newer. Read also about HTTP/2
Consider using (from your C code) the libcurl library for that (without using system(3) to run any curl(1) command). You need spend several days in reading about HTTP and libcurl.
Of course, someone could strace(1) your software (and find all details about your HTTP request and response), and understand the involved syscalls(2). See also credentials(7) and read Advanced Linux Programming and the documentation of GCC.
Learn also more about C, e.g. by reading n1570 and this C reference
Read also (and study documentation and source code) about the GDB debugger and ptrace(2).
Don't forget that the Linux kernel, the GCC compiler, the GDB debugger are all free software: you are allowed to download their source code, study it (it could take months), recompile that code (see LinuxFromScratch), and improve them.
There is no record/log of commands being executed by default. If you use bash, it has a history feature you can disable (with HISTSIZE=0). cron logs commands to syslog. ps will show processes that are currently running. If you run your c-program with ltrace or strace it will trivially tell you what it is doing. As will strings of the (stripped) binary.
Related
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/
I'm building a shared library in C, which other programs use. Sometimes, these other programs crash because of some error in my shared library. While reproducing these sort of bugs, it is very useful for me to know which functions of my library are being called, with what arguments and in what order. Of course I can add printf() calls to all my functions, or add breakpoints to all of them, but I figure there just has to be a better way to determine this.
Edit: since I'm doing this on OSX, dtrace and the related script dapptrace seem promising. However, after digging through some documentation I'm still a bit lost.
Say, my library is /path/to/libmystuff.so and I've got a program test which links to this library. Using dtrace, how would I bring up a list of all the function calls that reside in libmystuff.so?
You could use ltrace for that purpose if you work on a Linux system. The original poster shows, in the comments below, a solution that works on Mac OS X using dtrace.
I am assuming that you are working on Unix.
Use gdb for debugging purposes.
If your program has crashed.
you can use the core file generated for looking into the stack trace.
It will give all information that you have asked for.
for more information for checking the stacktrace using gdb with the core file see here.
You can also log the functions call on file system with all details like function name, arguments etc.
(Usually logging is help in Server-Clients application but I am not sure about your application).
This way You can trace all calls. You can also enable logging in debugging mode only. I hope this reply will be useful to you.
I have written a small custom web server application in C running on Linux. When the application receives a request it calls fork() and handles the request in a separate process, which is chrooted into a specific directory containing the files I want to make available.
I want to port the application to Windows, but neither fork() nor chroot() are available on this platform, and there don't seem to be any direct equivalents. Can you point me to a simple (and preferably well written) example of code that will provide this functionality in Windows? My C isn't all that good, so the simpler the better.
First of all, the Windows equivalent of chroot is RUNAS which is documented here. If you need to do this from a program, then studying this C++ source code should help you understand how to use the Windows API. It is not precisely the same as chroot() but Windows folk use it to create something like a chroot jail by creating a user with extremely limited permissions and only giving that user read permission on the application folder, and write permission on one folder for data.
You probably don't want to exactly emulate fork() on Windows because it doesn't sound like you need to go that far. To understand the Windows API for creating processes and how it differs from fork(), check Mr. Peabody Explains fork(). The actual current source code for Cygwin's fork implementation shows you the current state of the art.
The Microsoft documentation for CreateProcess() and CreateThread() are the place to look for more info on the differences between them.
And finally, if you don't want to learn all the nitty-gritty platform details, just write portable programs that work on Windows and Unix, why not just use the Apache Portable Runtime library itself. Here are some docs on process creation with some sample code, in C, to create a new process.
There's no such thing as fork() on Windows. You need to call CreateProcess() - this will start a separate process (mostly equivalent to calling fork() and then immediately exec() for the spawned process) and pass the parameters to it somehow. Since you seem to have all the data to process in a dedicated directory you can make use of lpCurrentDirectory parameter of CreateProcess() - just pass the directory path you previously used with chroot() there.
The absolutely simplest way of doing it is using Cygwin, the free Unix emulation layer for Windows. Download it and install a complete development environment. (Choose in the installer.) If you are lucky, you will be able to compile your program as is, no changes at all.
Of course there are downsides and some might consider this "cheating" but you asked for the simplest solution.
Without using a compatibility framework (Interix, Cygwin, ...) you're looking at using the Windows paradigm for this sort of thing.
fork/vfork is a cheap operation on UNIXes, which is why it's used often compared to multi-threading. the Windows equivalent - CreateProcess() - is by comparison an expensive operation, and for this reason you should look at using threads instead, creating them with CreateThread(). There's a lot of example code out there for CreateThread().
In terms of chroot(), Windows doesn't have this concept. There's libraries out there that claim to emulate what you need. However it depends why you want to chroot in the first place.
Reading comments, if it's simply to stop people going up the tree with ../../../../(etc), chroot would do the job, but it's no substitue for parsing input in the first place and making sure it's sane: i.e., if too many parents are specified, lock the user into a known root directory. Apache almost certainly does this as I've never had to create a chroot() environment for Apache to work...
Using fork/chroot is simply not how things are done on Windows. If you are concerned about security in subprocesses, maybe some form of virtualization or sandboxing is what you want to use. Passing complex information to the subprocess can be done by some form of RPC-solution.
It sounds to me as if you have designed your application in the Unix way, and now you want to run in on Windows without having to change anything. In that case, you may want to consider using Cygwin, but I'm not sure if/how Cygwin emulates chroot.
Consider SUA ( aka Windows Services for Unix ). It has nearly everything you need to port applications.
man chroot(interix)
I think the thing I want to do is called GUI/command line wrapping sftp(1). I need an easy way to start that program and react on its output while running. Additionally I have to be able to send input to it, full interaction is required.
I tried forkpty (emulated TTY), but there wasn't one good example findable using forkpty for that job, instead several warnings about overflows in in arguments and advisories not to use it. Another weird thing about this was the windowsize argument...
Please either give me one or many example(s) on how to call & interact with command line programs in C or another way of integrating sftp in an iPhone GUI
Rejoice! Expect was created to solve exactly your problem. It's based on Tcl, which is not so pleasant, but the tool is pleasant, it's really well designed, and there's a good book by Don Libes, who created the tool.
Expect scripts are written in Tcl, but it is totally easy to integrate a Tcl script into a C program such that other parts of the C program don't even know that Tcl is being used.
Have you used any of the popular scripting languages Ruby/Python/Perl/etc? They all have pretty full featured libraires for opening and communicating with other processes.
the subprocess module in python for example, or Popen in Ruby... there would also be lots of reference material around the web to help you out.
If a GUI was also required you could look at GTK extensions
Instead of calling sftp(1), how about using libssh? It has full sftp subsystem support.
I did an application that create a partintion and format the disk using system calls...
In the middle of the process there is a query asking to type the size of the disk... What can i do in my application in order to automaticly answer that query??
can you please help me?
This is certainly possible with, for instance libexpect but I never tried it (but Google found what seems to be a good example). On my Debian machine, man libexpect says:
libexpect - programmed dialogue library with interactive programs
This library contains functions that allow Expect to be used as a Tcl
extension or to be used directly from C or C++ (without Tcl).
Depending on your operating system (windows can do it for instance) you can have the stdin for the programmed redirected to come from an output of your program.
Maybe you can use system() do run utilities like expect to control the process
fortunately, There is nothing you can do. :)