Custom File Write/Read Syscall Handling

[Fadhil Kurnia]

Hi everyone, 

I tried to intercept some write(2) system calls issued by a running container. For a starter, I added fmt.Println("log") in "https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/sys_write.go#L46" to make sure I intercept at the right location, as what Ian Lewis said in Custom syscall Handling (google.com). It works well, whenever there is any write system call, my log write is triggered.

However, when I tried to do more complex logic (I tried to make an HTTP request when Sentry detects writes syscall, I tried to log the wrote request in a file using os.WriteFile), the running container stop immediately. 

Is this because of the limited syscall that Sentry can use? so I can't create an HTTP request or write a file from Sentry? Is there any better way to intercept file IO syscall in Sentry?

Thank you for the guidance!

[Ian Gudger]

On Mon, Sep 6, 2021 at 3:05 PM Fadhil Kurnia <fiku...@umass.edu> wrote:

Hi everyone, 

I tried to intercept some write(2) system calls issued by a running container. For a starter, I added fmt.Println("log") in "https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/sys_write.go#L46" to make sure I intercept at the right location, as what Ian Lewis said in Custom syscall Handling (google.com). It works well, whenever there is any write system call, my log write is triggered.

However, when I tried to do more complex logic (I tried to make an HTTP request when Sentry detects writes syscall, I tried to log the wrote request in a file using os.WriteFile), the running container stop immediately. 

Is this because of the limited syscall that Sentry can use?

Yes

so I can't create an HTTP request or write a file from Sentry?

You should be able to write a file if you open it before the sentry installs the syscall filters.

Is there any better way to intercept file IO syscall in Sentry?

Consider intercepting it in the gofer. Although the gofer is also run with syscall filters, it it probably fine to open them up in your fork to enable your use case.

Thank you for the guidance!

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/ac996fd6-474e-4d58-a494-54b6d2171686n%40googlegroups.com.