I'm looking at building a file system sync utility that monitors file system activity, but it appears that some of the file system monitoring features in the linux kernel are obsolete or not fully featured.
What my research as found
dnotify came first with notification has the features of notifying for delete,modify,access,attribs,create,move can determine file descriptor, however is now out dated by inotify and fanotify
inotify came out second with notification has the features of notifying access, modify, attrib, close, move, delete, create, etc however it does not give you a file descriptor or process and will be outdated by fanotify
fanotify is the latest which informs of access, modify, close, but does not inform of delete or attribs, but does provide file descriptor
I need a way of determining the process (e.g. from fd) and things like delete, modify, attribs, etc in order to sync everything, any suggestions? Unfortunately dnotify seems the best but most out-dated
You should use a library instead of inotify and friends - something like FAM or Gamin (it's the same API for both). This will make your program portable to other Unixes.
There's a good lib providing file descriptors or process with inotify. It has his own C API and the inotifywatch util (good for scripts), all in inotify-tools package.
http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/index.html
http://www.infoq.com/articles/inotify-linux-file-system-event-monitoring
I strongly disagree that fanotify will outdate inotify.
FAM and gamin are very good server/client options. Both of them use inotify as first option over the outdated dnotify and polls. I prefer gamin.
incron is a useful tool for the operations like this. You may create a configuration file for the directory or file that you want to watch.
http://inotify.aiken.cz/?section=incron&page=about&lang=en
in ubuntu
sudo apt-get install incron
/etc/incron.d/mynotification.conf
# notification for user creation
/home IN_ALL_EVENTS /opt/notify_user_created.sh $#
Related
I am aware that in distributions such as Ubuntu it is very easy to clear recent files, but I have three questions about recent files:
Does window manager handle these or the Linux itself?
Where can I find the history and how to manage them manually?
Are they usually in same place across different distributions?
I am sitting on Arch Linux with i3 window manager.
It is the desktop environment that does handle recent files (KDE uses baloo for example, Nautilus uses ~/.local/share/recently-used.xbel). There is no uniform way of handling recent files.
Potential candidates for what you are looking for are:
the DBus file managers interface, but I have not found anything relevant in the Dolphin implementation
the Recent File Storage Specification but I'm not aware of any implementations
the st_atime field from the struct stat structure written by the stat system call, but it would show any access, not only when a user opens the file and is not guaranteed to be available for the filesystem (see the noatime option when mounting a filesystem, in the Filesystem Independent Mount Options)
Your best bet is to write you own library which would then use KDE/GNOME libraries (or any other backend, if there are other desktop environments which implement these features) to get the data.
The i3 window manager does not implement this however since it does only handle window management and almost nothing else.
I'd like to intercept stat calls on a specific file and quickly perform an action ASAP once detected.
In the past I've used the INotify library but thats only worked for me when opening/writing/closing files etc. If I remember correctly, stat just reads the contents of the i-node on the file system so what would be the best way of intercepting the calls with a binary running in user space?
I guess this could also be generalized to intercepting system calls from userspace?
Also want to note that I do know the process I'm targeting but don't have any control over when it runs etc.
Thanks!
It is possible with the technique is known as function interposition.
It works for applications that you start or control the start-up environment to be able to set LD_PRELOAD environment variable.
You could use function hijacking at the library level with LD_PRELOAD, but this only works for dynamically linked binaries that are not setuid/setgid. For static or setuid/setgid binaries you have to implement a kernel module to hijack the function at the kernel level.
Is there a facility like fanotify, but for exec() operations? Something like kauth in MacOS, but in userland.
fanotify only seems to notify on (and allow/deny) file open/close/read/write.
I've seen code that can notify on fork and exec by other means (also here), but there is no way to allow or deny an exec. Also, it seems there are drawbacks to this approach, because not all kernels are compiled with netlink/proc connector, and it can get overwhelmed with events.
Perhaps you are looking for SELinux, a Linux kernel module which provides the enforcement of fine-grained security policies, like who or what gets to execute a certain file.
Looks like Linux finally added this feature to fanotify in kernel 5.0 (shipped in e.g. Ubuntu 19.04).
See man 2 fanotify_mark for details. The relevant flags are FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM.
I believe the "Process Events Connector" is what you are looking for. This interface will allow you to receive notifications of fork, exec, and setuid/setguid events.
Read more at LWN (https://lwn.net/Articles/157150/) and a great blog article (not mine) at http://netsplit.com/the-proc-connector-and-socket-filters.
What's the simplest way to detect CDROM media removal and insertion in Linux? I want to write some simple code to handle this. For example, just bind an event for media insertion and implement the handler.
Thanks!
Try man udev, or man hotplug.
The desktop 'standards' have options for this.
For example I think Gnome uses dbus for this:
http://www.linuxcertification.co.za/linux-training-sysfs-udev-hald-dbus
[..] These applications are mainly used by desktop environment to carry out tasks when an event occurs such as open the file browser when a USB drive is inserted or image application when a camera is inserted.
D-Bus is used for example to launch media players when a audio CD is inserted and to notify other applications of the currently playing song for example.
Configuration
You could just have your desktop shell (e.g. Gnome/nautilus) call your application when the even happens:
http://library.gnome.org/users/user-guide/stable/gosnautilus-61.html.en
Non-desktop
For the non-desktop version of this, man udev is indeed your friend. Info on writing udev rules is here:
http://reactivated.net/writing_udev_rules.html
The simplest way from user space is to grep the output of the mount command, provided you have configured the CDROM for automount ( in /etc/fstab).But if you want to have an asynchronous notification, you might need to look into udev rules and uevents.
Is there a clean way to detect or receive events when a user inserts or removes a CD on a Linux platform?
Udev monitors hardware and forwards events to dbus. You just need some dbus listener. A quick check using the dbus-monitor tool shows this in my system:
dbus-monitor --system
signal sender=:1.15 -> dest=(null destination) serial=144 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sr0"
This is the DeviceChanged event from Udisks, and the device path is included.
So, in whatever programming language you want that supports dbus bindings you can listen for those (system bus) events.
Traditionally there has been HAL (Hardware Abstraction Layer) for this, but the web page says
HAL is in maintenance mode - no new
features are added. All future
development focuses on udisks, UPower
and other parts of the stack. See
Software/DeviceKit for more
information.
and the DeviceKit page lists
udisks, a D-Bus interface for dealing with storage devices
So udisks should probably be what you are asking for.
The best way I was able to find was Halevt. Halevt is apparently a higher level abstraction than using HAL directly. It uses an XML based configuration file that may or may not be to your liking. The configuration file properties documentation is somewhat lacking. A list of all the supported properties are listed here:
http://www.marcuscom.com/hal-spec/hal-spec.html
Also, the link to Halevt: http://www.nongnu.org/halevt/