wolfcw / libfaketime

libfaketime modifies the system time for a single application
https://github.com/wolfcw/libfaketime
GNU General Public License v2.0
2.64k stars 321 forks source link

libfaketime: Set 777 on shared memory #379

Closed nekromant closed 2 years ago

nekromant commented 2 years ago

I've been playing around with libfaketime PRELOAD'ed in docker. It seems that whenever 'su' is involved things tend to break with semaphore permissions problems. This aims to fix it by making shared memory world-accessible. It's somewhat a security risk, but come on, nobody should ever be using this in production environments anyway!

And for testing this doesn't really matter ;)

In other words, how to use it to send a whole docker container back (or forth) in time:

echo "-1d x1,0" > /etc/faketimerc
chmod -Rfv u+s /usr/local/lib/faketime/*
echo "/usr/local/lib/faketime/" > /etc/ld.so.conf.d/90-faketime.conf
ldconfig
echo "libfaketimeMT.so.1" > /etc/ld.so.preload

Signed-off-by: Andrew Andrianov andrew@ncrmnt.org

wolfcw commented 2 years ago

Thanks for the suggestion and the PR!

Given we don't know who is using libfaketime and in which environments, I'm a bit hesistant about making things world-writable by default. However, I'd be fine with yet another additional environment variable to pass a umask or other typical notation of file permissions, which then is used when creating those files.

Also, eventually, an easier solution would be to change ownership (or broaden permissions) in Dockerfiles or scripts where it seems necessary. su and other suidroot binaries don't LD_PRELOAD anything anyway, so the file permissions might not be the only problem here when we consider syncing faketime settings across process hierarchies.

nekromant commented 2 years ago

I see no problem with making it yet another environment variable. Just give me a few days to implement & test this in the merge request.

Question: If we run complex containers that spawn other processes. Would faketimerc be a good place to store configuration data apart from env variables?

Regarding preloading of suidroot binaries - if I got it right, there's a way around the restriction. Took me a while. I guess it should be added to the docs:

LD_PRELOAD A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set- user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set-user-ID will be loaded.

So basically this seems to work for me:

chmod -Rfv u+s /usr/local/lib/faketime/*
echo "/usr/local/lib/faketime/" > /etc/ld.so.conf.d/90-faketime.conf
ldconfig
echo "libfaketimeMT.so.1" > /etc/ld.so.preload
wolfcw commented 2 years ago

Sounds cool, thanks for working on that! And yes, we should add the preloading of set-uid libraries to the docs; not sure how portable that is, but it seems very useful at least on Linux.

There's no functional difference between using environment variables or files to specify the faked time. Depending on the use case, the one might be easier to provide than the other, or just vice versa. File contents are typically easier to change from outside at run-time, but there's no one-size-fits-all answer there.

Typically, one wants to start a process with a specified faked time, and then just have it passed down to child processes through the shared memory stuff we're dealing with here. This avoids that child processes that are spawned with a larger delay (e.g., five minutes after the parent process) start with the same old faked time as their parent process. Whether that's an issue again depends on how exact all the processes need to be synchronized to each other, and of course whether absolute/start-at timestamps are used; when using offsets (like "-1y"), it doesn't make a difference.

wolfcw commented 2 years ago

Making any files world-writable should be explicitly requested by the libfaketime users and not default. Please wrap, e.g., into activation by an environment variable trigger.