I am interested in starting a daemon inside an lxc container with its stdin/stdout as a socket passed from the host, inetd style. Is this possible?
Be advised, if using an LXC "snapshot" clone, with a directory backing store (which thus uses overlayfs), then Unix FIFO pipes are currently broken. See:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1214500
I don't think LXC has native support, but you could always just run your lxc command under xinetd to get what you want. Or write your own server that talks sockets on one side and talks LXC (via popen() or something) on the other side.
inetd is a daemon that starts (non-daemonic) programs that use stdin/stdout to listen/talk to you
The LXC utilities lxc-start and lxc-execute insist on closing all open file descriptors (including stdin/stdout) making them useless with inetd. They eventually call clone(2), however, and so can you, writing your own C wrapper like this:
#define STACKSIZE 409600
/* choose your favourite brand of isolationism below */
#define SPLENDID_ISOLATION (CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWNET)
int exec_command(void* arg) {
/* don't close stdin/stdout here! */
execl("command", "command", arg, NULL);
return 1;
}
void main(int argc, char **argv) {
void *stack = malloc(STACKSIZE) + STACKSIZE - 1; /* grows downwards */
clone(&exec_command, stack, SIGCHLD|CLONE_VFORK|SPLENDID_ISOLATION, argv[1]);
wait(NULL);
}
This wrapper can then be run under inetd.
Related
I'm building a POC Android app that needs to communicate with an ELF binary over a Unix domain socket server that the binary binds to and listens on. The app is meant for rooted phones and executes the binary as a superuser upon launch. I need to connect with the binary from my client residing in native code, which I'm presently failing to do.
I'm using a self-ported, stripped down version of libsocket to implement the domain socket functionality for both the binary and the Android app (through JNI). The binary communicates perfectly with a command line client, however, it fails to connect with the client that I've implemented in JNI code. I've made sure that the binary is running from /data/data/<my_package_name>/files and that the server socket has public access (777).
While researching the above problem, I stumbled across the fact that NDK requires LocalSockets to be in the Linux abstract namespace. My server (arm binary) binds to an absolute path (/data/data/<my_package_name>/files/serversocket) as libsocket does not support the abstract namespace for unix domain sockets (due to the usage of strlen() and strncopy() which do not support strings beginning with \0).
The following is the code for create_socket from libsocket that's failing with a negative fd.
int create_socket(const char* path, int flags) {
if (path == NULL) {
return -1;
}
if (strlen(path) > sizeof(((struct sockaddr_un*) 0)->sun_path) - 1) {
return -1;
}
int fd = socket(AF_LOCAL, SOCK_STREAM | flags, 0);
if (fd < 0) {
return -1;
}
struct sockaddr_un addr;
memset(&addr, 0, sizeof(addr));
addr.sun_family = AF_LOCAL;
strncpy(addr.sun_path, path, sizeof(addr.sun_path) - 1);
// the connect call below fails, errno is set to 13 (EACCESS)
if (connect(fd, (struct sockaddr*) &addr, sizeof(addr.sun_family) + strlen(addr.sun_path))) {
close(fd);
return -1;
}
return fd;
}
EDIT :
In the above code, the call to connect() fails, with errno being set to 13 (EACCESS). This seems to be an insufficient privileges problem.
I'm wondering if there's any way for me to connect my client to an absolute path from within NDK. It works just fine when I package the client in an ELF executable that runs as superuser, am I missing something obvious here?
To anyone who might be following this, it is necessary to set appropriate permissions on the socket pseudo file manually every time it is launched as root, else connect() fails with errno being set to EACCESS. I'm yet to find a better solution to this.
The question may seem naive, but I'm new to kernel/driver programming. I created a device mapper over a block device, which is working fine. It's constructor/destructor and map methods are called.
Now, I'm trying to write an ioctl for this mapper. When ioctl is written for a device, it has the following signature:
int ioctl(int d, /* other args */);
A file structure/descriptor is expected in ioctl. This can be easily used by application process as it has access to file.
But the ioctl for device mapper has the following signature ( in struct target_type):
typedef int (*dm_ioctl_fn) (struct dm_target *ti, unsigned int cmd,
unsigned long arg);
How can user application get access to device mapper with ioctl without having knowledge of struct dm_target ?
-Ioctl which stand for Input Output control is a system call used in linux to implement system calls which are not be available in the
kernel by default.
-The major use of this is in case of handling some specific operations of a device for which the kernel does not have a system call by default. For eg: Ejecting the media from a "CD" drive. An ioctl command is implemented to give the eject system call to the cd drive.
-ioctl(fd, cmd , INPARAM or OUTPARAM);
|
3rd argument is INPARAM or OUTPARAM i.e we don't have to read a device, then how how to interact with device ? use ioctl.
-open ioctl.h and check you will get more information
#define "ioctl name" __IOX("magic number","command number","argument type")
static long char_dev_ioctl( struct file *filp, unsigned int cmd, unsigned long arg)
{
/* verify argument using access_ok() */
/* impliment support of ioctl commands */
}
According to this, I'm using the system() (QProcess) function from inside my program to call the gpio program.
It works. But I've noticed I need to run my app two times, in fact it only works at the second time. It seems the call to gpio must be done in another process, as pointed here.
Should this problem be approached with QProcess::setupChildProcess()?
I extended QProcess overwriting setupChildProcess and then just instanciated SandboxProcess in the constructor of my app. Unfortunately, this didn't worked.
class SandboxProcess : public QProcess
{
protected:
void setupChildProcess();
};
void SandboxProcess::setupChildProcess()
{
QString program = "/usr/local/bin/gpio";
QStringList arguments;
arguments << "export" << QString::number(4) << "out";
start(program, arguments);
}
I guess QProcess::setupChildProcess() doesn't help because it's own process starts after the main app proccess. So the main app still fells like the export command was not executed.
At this point I see two options:
To make a ManagerApp, which call gpio (to do the exports) and then call (another) MyApp which will actually access the exported devices.
Use the gpio app directly and listen to their stdout via signal/slot, using QProcess.
I have to stop the earlier instances of processes before starting a new instance. For this i need to system call or a C library call.
Presently i use "system("killall name"). This works but I want to replace this with any equivalent system(2)/library(3) calls. What is the option?
Also to remove files from directory as in "system("rm -f /opt/files*")",
what would be the alternate library(3)/system(2) call?
Pleas note * in file names, remove all files with one call.
regards,
AK
As far as I know there is no general way to do it, as there is no general way to get the pid by its process name.
You have to collect the pids of related processes and call the int kill(pid_t pid, int signo); function
At least you can try to check how its implemented by killall itself
A small addition from Ben's link, killall invokes following lines, i.e. collecting the pids of related process by find_pid_by_name function, implementation of which can be found here
pidList = find_pid_by_name(arg);
if (*pidList == 0) {
errors++;
if (!quiet)
bb_error_msg("%s: no process killed", arg);
} else {
pid_t *pl;
for (pl = pidList; *pl; pl++) {
if (*pl == pid)
continue;
if (kill(*pl, signo) == 0)
continue;
errors++;
if (!quiet)
bb_perror_msg("can't kill pid %d", (int)*pl);
}
}
You can see the implementation in busybox here: http://git.busybox.net/busybox/tree/procps/kill.c
You can also link with busybox as a shared library and invoke its kill_main instead of launching a separate process. It looks fairly well behaved for embedding like this -- always returns normally, never calls exit() -- although you may have difficultly getting error information beyond the return code. (But you aren't getting that via system() either).
If I compile and run the code as-is, the process will run with 1 thread. If I uncomment the commented out section and then compile and run it, it runs with 2 threads.
I am compiling the code with this command:
g++ pkg-config gtkmm-2.4 --cflags --libs test.cpp
When the program is running I can check how many threads are created with:
ps -mC a.out
If I look at the second thread in ddd, I can see that it is running g_main_loop_run. This confuses me:
What is the purpose of this thread?
Why does adding a toolbar button create a new thread?
I thought g_main_loop_run() should only ever run in one thread (unless you use the GDK_THREADS_ENTER/GDK_THREADS_LEAVE macros). Since I am running Gtk::Main::Run() in my main thread am breaking the rules?
Thanks in advance for any help. It's driving me crazy.
#include <gtkmm.h>
bool OnDeleteEvent(GdkEventAny* PtrGdkEventAny)
{
Gtk::Main::quit();
return(true);
}
void OnExecuteButtonClicked()
{
}
int main(int argc, char *argv[])
{
new Gtk::Main(0, NULL);
Gtk::Window *ptrWindow = new Gtk::Window;
ptrWindow->signal_delete_event().connect(sigc::ptr_fun(&OnDeleteEvent));
/*
Gtk::Toolbar *ptrToolBar = manage(new Gtk::Toolbar);
Gtk::ToolButton *ptrToolButton;
ptrToolButton = manage( new Gtk::ToolButton(Gtk::Stock::EXECUTE));
ptrToolBar->append(*ptrToolButton, sigc::ptr_fun(&OnExecuteButtonClicked));
ptrWindow->add(*ptrToolBar);
*/
ptrWindow->show_all();
Gtk::Main::run();
return (0);
}
Sometimes GThreads are created when you use functions that rely on async behaviour. These usually create a GTask internally (with g_task_run_in_thread and friends) and run the synchronous version in a seperate thread (except for those being nativly async or async-able, those usually won't spawn another thread). Usually this is IO (i.e. GtkBuilder), Socket and IPC (dbus) related - so mostly glib stuff.
There might also be occasions which I am not aware of, that will spawn additional threads, the mainloop itself is strictly single threaded.
So in your case I can only think of two thing that could trigger this: The Stock image that is loaded from your local disk or the styling information of your theme.