rflament / loggedfs Goto Github PK

I notice that i get a UID output from loggedFS ( the main draw to it was finding out who edited things ), but we're 1 step away from printing the actual linux username which would be a lot better to read.

Any hope adding this?

Hello,

we are having websites which are getting injected with malicious scripts, 8x7ash2hbx8.php and so on. We are trying to find out the root of the problem, so we know exactly what process/script/path a specific file wrote. We have an exact date of file creation and were hoping to use LoggedFS to find it out.

But when we mount the website directory, we get a "Forbidden" on our webserver/website. Is the whole directory not accessable by other processes/users while logging?

Regards,
Dennis

I ran the latest release of pjdfstest against LoggedFS.

The test link/00.t fails the following sub-tests (out of 202 total):

• 8 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,nlink', expected regular,3, got regular,2
• 13 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,mode,nlink,uid,gid', expected regular,0201,3,65534,65533, got regular,0644,2,0,0
• 15 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected regular,0201,3,65534,65533, got regular,0644,3,0,0
• 18 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected regular,0201,2,65534,65533, got regular,0201,3,65534,65533
• 19 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected regular,0201,2,65534,65533, got regular,0644,3,0,0
• 22 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected regular,0201,1,65534,65533, got regular,0201,3,65534,65533
• 34 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,nlink', expected fifo,3, got fifo,2
• 39 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,mode,nlink,uid,gid', expected fifo,0201,3,65534,65533, got fifo,0644,2,0,0
• 41 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected fifo,0201,3,65534,65533, got fifo,0644,3,0,0
• 44 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected fifo,0201,2,65534,65533, got fifo,0201,3,65534,65533
• 45 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected fifo,0201,2,65534,65533, got fifo,0644,3,0,0
• 48 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected fifo,0201,1,65534,65533, got fifo,0201,3,65534,65533
• 60 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,nlink', expected block,3, got block,2
• 65 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,mode,nlink,uid,gid', expected block,0201,3,65534,65533, got block,0644,2,0,0
• 67 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected block,0201,3,65534,65533, got block,0644,3,0,0
• 70 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected block,0201,2,65534,65533, got block,0201,3,65534,65533
• 71 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected block,0201,2,65534,65533, got block,0644,3,0,0
• 74 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected block,0201,1,65534,65533, got block,0201,3,65534,65533
• 86 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,nlink', expected char,3, got char,2
• 91 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,mode,nlink,uid,gid', expected char,0201,3,65534,65533, got char,0644,2,0,0
• 93 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected char,0201,3,65534,65533, got char,0644,3,0,0
• 96 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected char,0201,2,65534,65533, got char,0201,3,65534,65533
• 97 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected char,0201,2,65534,65533, got char,0644,3,0,0
• 100 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected char,0201,1,65534,65533, got char,0201,3,65534,65533
• 112 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,nlink', expected socket,3, got socket,2
• 117 - tried 'lstat pjdfstest_188e97618779bc8797c35c5fd15f763e type,mode,nlink,uid,gid', expected socket,0201,3,65534,65533, got socket,0777,2,0,0
• 119 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected socket,0201,3,65534,65533, got socket,0777,3,0,0
• 122 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected socket,0201,2,65534,65533, got socket,0201,3,65534,65533
• 123 - tried 'lstat pjdfstest_626e9e52477a6690014e2165873670a0 type,mode,nlink,uid,gid', expected socket,0201,2,65534,65533, got socket,0777,3,0,0
• 126 - tried 'lstat pjdfstest_6f3e5f2e79b4b8036844c032342395fd type,mode,nlink,uid,gid', expected socket,0201,1,65534,65533, got socket,0201,3,65534,65533

I attached the corresponding log from LoggedFS: test_link_00_err_redux.log

I am running openSUSE Leap 42.3, latest patch-level, Kernel 4.4.103 (-36-default x86_64), fuse 2.9.3 (-11.3.x86_64). The filesystem underneath is ext4. It passed all tests.

Closely related to #16: In your implementation of open, you are using the open system call. You should be using the openat system call instead.

rlog is marked as unmaintained upstream. Even encfs, where is stems from originally and where it was used for a long time, moved to easylogging++ (https://github.com/muflihun/easyloggingpp).
I'm not saying loggedfs should use the same, but staying with rlog is not really a good option.

I ran into this issue testing my Python implementation - your C++ implementation shows the same problem:

You implement truncate by calling the truncate system call. As you might have noticed, there is no truncateat system call which would be required for truncating something with a path relative to a file descriptor. So your implementation assumes that its current working directory is never changed throughout its lifetime.

I have spend a while researching it ( 1, 2 ) and it appears that the best solution is to just divert from the truncate system call to an openat-ftruncate-close-sequence. I have successfully tested this with my Python implementation.

EDIT: Actually, this issue applies to most system calls that you use which take a path as an argument. You are always relying on the current working directory. You should use the savefd file descriptor throughout your code and specify paths relative to it.

It would be pretty cool to know how to create an entry in fstab so the system starts logging automatically.

Especially an example with a log location and config file would be helpful.

I ran the latest release of pjdfstest against LoggedFS.

LoggedFS consistently crashes (i.e. does not permit any further operations on it, returning ENOTCONN) after the following tests:

• truncate/03.t
• open/03.t
• mkdir/03.t
• chmod/03.t
• mknod/03.t
• mkfifo/03.t
• unlink/03.t
• symlink/03.t
• link/03.t
• chown/03.t
• ftruncate/03.t
• rmdir/03.t
• rename/02.t

All of those tests have in common that they try to check the behavior of the filesystem when operations with path names exceeded PATH_MAX characters are attempted. It is expected that the filessystem returns ENAMETOOLONG.

I am running openSUSE Leap 42.3, latest patch-level, Kernel 4.4.103 (-36-default x86_64), fuse 2.9.3 (-11.3.x86_64). The filesystem underneath is ext4. PATH_MAX for both ext4 and LoggedFS equaled 4096. pjdfstest was configured for ext4. The filesystem underneath on its own passed all tests.

Hello, I am studying your project.
Could you tell me
how I can increase the default block size (4KB) to 64KB?

Hey, great piece of software; i'm using it to monitor systems now :)

The logging feature is not working for me in ubuntu 20.04 straight from the repo ( not sure what version i picked up )
It writes something like bootup messages and then logs nothing.
Switch over to -f and i get the messages.

Quite a bummer.. can it be fixed? until then i'll be doing loggedfs > /var/log/loggedfs.log 2>&1

I ran the latest release of pjdfstest against LoggedFS.

The test utimensat/02.t fails the following sub-tests (out of 10 total):

• 4 - tried 'lstat pjdfstest_5e54ac77641cc205fe486e0bc5946422 atime', expected 1900000000, got 1514739815
• 7 - tried 'lstat pjdfstest_5e54ac77641cc205fe486e0bc5946422 atime', expected 1900000000, got 1514739815
• 8 - tried 'lstat pjdfstest_5e54ac77641cc205fe486e0bc5946422 mtime', expected 1950000000, got 1514739815

I attached the corresponding log from LoggedFS: test_utimensat_02_err_redux.log

The test utimensat/05.t fails the following sub-tests (out of 16 total):

• 7 - tried 'lstat pjdfstest_15a42ebdf2336eb173a206f395b33b44 atime', expected 1960000000, got 1514739816
• 8 - tried 'lstat pjdfstest_15a42ebdf2336eb173a206f395b33b44 mtime', expected 1970000000, got 1514739816
• 13 - tried 'lstat pjdfstest_15a42ebdf2336eb173a206f395b33b44 mtime', expected 1970000000, got 1514739816

I attached the corresponding log from LoggedFS: test_utimensat_05_err_redux.log

I see the exact same tests fail in another FUSE filesystem, so I suspect it's FUSE's fault. The failures are consistent across multiple Linux distributions with Kernels 4.4 to 4.10 with FUSE 2.9.x releases. (The filesystem underneath in every case was ext4. It always passed all tests.) I'd love to have a confirmation though before I file a bug there.

This third issue concludes my series of reports. LoggedFS passed all other tests that pjdfstest has to offer. Impressive - congratulations.

With commit 02339be and earlier, things work as expected. With commit 6a85fbd and later (with the inclusion of easylogging, loggedfs essentially does not log anything for me anymore - even if I allow everything in the XML configuration file.

All I get is something along those lines ...

2019-04-11 12:42:10,442 INFO [default] Configuration file : /demo/test_loggedfs_cfg.xml
2019-04-11 12:42:10,442 INFO [default] LoggedFS running as a public filesystem
2019-04-11 12:42:10,442 INFO [default] LoggedFS starting at /demo/test_mount/test_child.
2019-04-11 12:42:10,442 INFO [default] Using configuration file /demo/test_loggedfs_cfg.xml.
2019-04-11 12:42:10,442 INFO [default] chdir to /demo/test_mount/test_child
2019-04-11 12:42:10,755 INFO [default] LoggedFS closing.

... although I ran a few actions on it, like creating a file, changing it, etc.

Testing on openSUSE Leap 42.3 x86_64, patch level as of today. Tried to compile with both g++ 4.7 and 6.2.

There is a list of fuse filesystems, would you like to add yours there?
https://github.com/libfuse/libfuse/wiki/Filesystems
Do you consider your fs already mature and production-quality?

Thanks a lot for the very needed for me filesystem.