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.
Related
I am interested in writing my own tool in bash to act in place of my current network controller (wpa_supplicant) if possible. For example if I want to issue commands in order to begin a wps authentication session with a router's external registrar, is it possible, without using any pre-built tools, to communicate with the kernel to directly access the hardware? I have been told that I can achieve what I desire with a bash plugin called ctypes.sh but I am not too certain.
Generally speaking, the Linux kernel can interact with user-space through the following mechanisms:
Syscalls
Devices in /dev
Entries in /sys
Entries in /proc
Syscalls cannot be directly used from Bash but you need at least a binding through a C program.
You can create a Linux kernel driver or module which reads/writes data in an entry under /proc or /sys and then use a bash program to interact with it. Even if technically feasible, my personal opinion is that it is an overkill, and the usual C/C++ user-level programming with proper entries in /dev is much better.
No, this is generally not possible. Shell scripts can mess around in /proc, but they don't have the ability to perform arbitrary IOCTLs or even multi-step interactive IO. It's the wrong tool for the job.
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 $#
We are looking into implementing an in-memory utility which can recover the system in case of disk/filesystem lockup. This utility has to detect the lockup and take corrective action like rebooting or just shutting down interface.
The server platform is Gentoo Linux 2.4
Any suggestions on - any existing utility or which scripting method will work best (expect, native C++)?
you'll want S.M.A.R.T. monitoring tools (smartmontools)
http://en.wikipedia.org/wiki/S.M.A.R.T.
Note that not all statistics correlate with impending drive failure, and sometimes (for some brands and models) you may need to pass in special flags or you will get garbage. See the wikipedia article for which attributes really indicate danger.
The command is smartctl. You may need to be sudo. smartctl --all will give a summary of all drives, spinning them up very briefly to check their health.
What type of errors are you looking for?
smartmontools and smartd which ship with most distros should be able to help you. They work at a low level with the disk.
SMART on Wikipedia
smartmontools
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/
A linux machine freezes few hours after booting and running software (including custom drivers). I'm looking a method to debug such problem. Recently, there has been significant progress in Linux Kernel debugging techniques, hasn't it?
I kindly ask to share some experience on the topic.
If you can reproduce the problem inside a VM, there is indeed a fairly new (AFAIK) technique which might be useful: debugging the virtual machine from the host machine it runs on.
See for example this:
Debugging Linux Kernel in VMWare with Windows host
VMware Workstation 7 also enables a powerful technique that lets you record system execution deterministically and then replay it as desired, even backwards. So as soon as the system crashes you can go backwards and see what was happening then (and even try changing something and see if it still crashes). IIRC I read somewhere you can't do this and debug the kernel using VMware/gdb at the same time.
Obviously, you need a VMM for this. I don't know what VMM's other than VMware's VMM family support this, and I don't know if any free VMware versions support this. Likely not; one can't really expect a commercial company to give away everything for free. The trial version is 30 days.
If your custom drivers are for hardware inside the machine, then I suppose this probably won't work.
SystemTap seems to be to Linux what Dtrace is to Solaris .. however I find it rather hostile to use. Still, you may want to give it a try. NB: compile the kernel with debug info and spend some time with the kernel instrumentation hooks.
This is why so many are still using printk() after empirically narrowing a bug down to a specific module.
I'm not recommending it, just pointing out that it exists. I may not be smart enough to appreciate some underlying beauty .. I just write drivers for odd devices.
There are many and varied techniques depending on the sort of problems you want to debug. In your case the first question is "is the system really frozen?". You can enable the magic sysrq key and examine the system state at freeze and go from there.
Probably the most directly powerful method is to enable the kernel debugger and connect to it via a serial cable.
One option is to use Kprobes. A quick search on google will show you all the information you need. It isn't particularly hard to use. Kprobes was created by IBM I believe as a solution for kernel debugging. It is essentially a elaborate form of printk() however it allows you to handle any "breakpoints" you insert using handlers. It may be what you are looking for. All you need to do is write and 'insmod' a module into the kernel which will handle any "breakpoints" hit that you specify in the module.
Hope that can be a useful option...
How I debug this kind of bug, was to run my OS inside the VirtualBox, and compile the kernel with kgdb builtin. Then I setup a serial console on the VirtualBox so that I can gdb to the kernel inside the VirtualBox's OS via the serial console. Anytime the OS hang, just like magic sysrq key, I can enter ctrl-c on the gdb to stop and understand the kernel at that point in time.
Normally kernel stack tracing is just too difficult to pinpoint the culprit process, so the best way I think is still generic "top" command, just looking at the application logs to see what are the cause of hanging - this will need a reboot to see the log of course.