Add API for `fanotify_event_info_fid`

[rawhuul]

Hi dev,

I see there is no implementation of fanotify_event_info_fid, are you planning to add it? If not, is there any workaround to that?

[pantsman0]

Hi @rawhuul, it would require a redesign of the high level and low level APIs to support the reporting flags that send fanotify_event_info_fid and fanotify_event_info_pidfd. Same with supporting error reporting through fanotify_event_info_error.

Do you have a specific use-case that you are looking to achieve? If so, I can help you craft a PR to get the APIs updated.

[rawhuul]

Yup i do understand that it will be a breaking change, do you have any plan in future to add this API? I am currently making a NFS tracer which can trace which file is being operated on currently for which I need to get fid event file descriptor and check whether the header has correct info_type or not, other than that I will be need to use fanotify_event_metadata which will provide event's file descriptor, and will be also using to traceback in /proc/<pid>, where pid will be taken from metadata

[pantsman0]

There aren't currently an plans for API changes, though I am happy to work with you to add features to the crate

[rawhuul]

Yeah, will surely look into it

[pantsman0]

Actually, I had a look at the fanotify API again today and it seemed OK to implement as long as I hacked around the DST in the fanotify_event_info_fid struct. Rust supports DSTs but it's half baked so you can't construct them without making a sized impl and coercing to an unsized version, so it's not usable for us. There is a work around by creating our own pointer metadata, but that's stuck on nightly.

I have done an initial impl in a new branch if you want to give it a go: https://github.com/Percivalll/fanotify-rs/tree/info_fid.

There aren't any extra tests yet, so I would love reports for any bugs you find.

[pantsman0]

@rawhuul I don't know if you started looking, but I just pushed some more code to properly handle FAN_EVENT_INFO_TYPE_DFID_NAME returning a string with the name of the file being operated on.

This may still need work though, as the file path should technically be of type OsString instead of CString.

[rawhuul]

Thanks @pantsman0, I will look into it and surely get back to you -- currently occupied. Interesting, you made FanotifyEventInfoHeader as libc crate currently lacks it

[pantsman0]

Yeah, unfortunately even the proposed patches aren't sufficient as the fid struct is added with the [u8;0] instead of properly modelling the DST behaviour.

[pantsman0]

If anyone sees this in the future and is wondering why I don't want to use DSTs, please have a look at the kind of stuff you need to do to make them work. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fd082276db55c278b3a37b4380ca912a

That code is also likely unsound as de-allocating a pointer is required to be called with the same layout as allocation, and there is no way to do that on a Box. Implementing Drop for Box<Self> will also fail as you need to move the pointer out of the box, which you can't do since you drop on takes a mutable borrow.

[rawhuul]

Yeah, unfortunately even the proposed patches aren't sufficient as the fid struct is added with the [u8;0] instead of properly modelling the DST behaviour.

Indeed, I tried myself the same and ran into alignment issue.

I just pushed some more code to properly handle FAN_EVENT_INFO_TYPE_DFID_NAME returning a string with the name of the file being operated on.

Yes, it works for me, thanks for the great work