CODEWITHSUNDEEP
clinuxdockerpopen
user2384330
user2384330

Reputation: 115

Access host data when running a program from docker container

I'm trying to run the following in a C program hosted in a docker container;

#include <stdio.h>
#include <stdlib.h>


int main( int argc, char *argv[] )
{

  FILE *fp;
  char path[1035];

  /* Open the command for reading. */
  fp = popen("sudo udevadm info --query=all --name=/dev/sda", "r");
  if (fp == NULL) {
    printf("Failed to run command\n" );
    exit(1);
  }

  /* Read the output a line at a time - output it. */
  while (fgets(path, sizeof(path), fp) != NULL) {
    printf("%s", path);
  }

  /* close */
  pclose(fp);

  return 0;
}

However it's giving me a Unknown device "/dev/sda": No such device error.

Presumably because it can't access the hosts disk data. Is there a way to get the host data instead of the docker container's data through popen?

Any help is appreciated, many thanks!

Edit - Agree with the comments/answers saying that giving --privileged is a bad idea. As a work-around; if I created a dll out of the application, and kept it in the host, would it be possible to access this dll from the container?

Upvotes: 0

Views: 60

Answers (1)

David Maze
David Maze

Reputation: 159771

Not really, especially when it comes to managing raw physical devices. If you can access /dev/sda then you can access the raw bits of the physical disk and break or circumvent any sort of security controls that might be there. This isn't normally allowed, and a container has both restrictions on Linux capabilities and also additional device-mapping controls that prevent you from doing it.

If you want to manage aspects of the host system like physical devices, you generally need to do it without a container.

In principle you might be able to docker run --privileged your container, or use docker run --device /dev/sda --cap-add SYS_ADMIN to give your container the required permissions. But this is fundamentally giving the container permission to overwrite the boot loader, replace the kernel, and make arbitrary changes to anything backed by disk; you're all but completely circumventing Docker's core isolation features.

Also note that sudo doesn't generally work in a container, since it's very hard to securely set a user password and you often won't be able to prompt for one either. You shouldn't hard-code it in your application code.

Upvotes: 1

Related Questions