I have pcspkr in blacklisted in /etc/modprobe.d/pcspkr.conf. However, I can manually load the module using modprobe.
I'm guessing, some other component will be able to do the same via module alias mechanism. Is there a way to permanently block automatic loading of a specific kernel module?
My use case is that I want to experiment with an alternative driver than the one provided in-tree. For this, I do not want the system's default driver showing up. I do not want to delete the golden driver provided by the kernel and screw up either.
What options do I have ?
Related
I am running into a problem with labeling. In order to lock down access to a file /etc/avahi/avahi-daemon.conf I decided to label it as a part of the avahi_t domain.
I am working on an embedded system. When I boot up the system from a version update, the file system is relabeled with the .autorelabel flag set.
Unfortunately the file /etc/avahi/avahi-daemon.conf remains in the unlabeled_t type. Due to the label being wrong, it is unable to read the file and avahi fails to initialize properly with an avc read denied on an unlabeled_t file. I want to have the label correctly set and not modify policy to read an unlabeled file. I also want it to be protected so the configuration can not be modified.
I have properly labeled it in the .fc file with the following:
/etc/avahi/avahi-daemon.conf -- gen_context(system_u:object_r:avahi_t,s0)
When I try a restorecon on the file system it attempts to relabel the file but is blocked by SELinux with a relabelto avc violation. Similarly changing it with chcon -t fails to change it. I do not wish to open relabelto up on an embedded system as it can then be relabeled and take down the avahi initialization. If I take out the SD card, and relabel the file on a different system. And place it back into the target system it is properly labeled. And avahi operates correctly. So I am certain that the labeling is causing the problem.
In looking in the reference policy an init_daemon_domain(avahi_t,avahi_exec_t) is being performed.
In looking at the documentation for init_daemon_domain() it states the following:
"The types will be made usable as a domain and file, making calls to domain_type() and files_type() redundant."
This is unusual in that if I add files_type(avahi_t) to the .te file, it properly labels after version update.
I am really wanting to know more information about this, and unfortunately my searches on the internet have been less than fruitful in this regard.
Is the documentation for SELinux wrong? Am I missing something about init_daemon_domain() in that it only works with processes and not files?
Or is the files_type(avahi_t) truly needed?
I know this comes off as a trivial issue since there is a path to where it is working. However I am hoping to get an explanation as to why files_type(avahi_t) is necessary?
Thanks
I have modified the default "nvme" device driver to suit my project and I am trying to automatically load the modified nvme driver (mnvme) at boot time but I am not successful.
I have edited /lib/modules/{kernel-version}/modules.alias file to include "mnvme" instead of "nvme" but the default "nvme" keeps getting loaded.
I also see mnvme: module verification failed: signature and/or required key missing - tainting kernel on kernel messages.
Note: I am able to manually remove "nvme" and load "mnvme" using rmmod and insmod commands respectively. I would prefer to do it automatically at boot time
Thanks,
Bala.
To automatically load your module:
Copy all .ko files related to your module into respective location under /lib/modules/{kernel-version}/kernel/, e.g. under /lib/modules/4.1.19-v7+/kernel/drivers/nvme/ for nvme driver.
Run depmod -a. That should update information required by modprobe which is used to automatically load the modified module. A useful resource for how kernel modules get loaded is section 1.2 'How Do Modules Get Into The Kernel?' of this guide http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf.
If you've modified any headers that you need in user space then make sure to update relevant header file under /usr/include.
To avoid taint message, the commit the changes you've made, e.g. git commit -sam "....".
I want to write a test driver for mcspi and want to give all configuration in my driver file (instead of using user space application I want to use driver as a test driver and want to create .ko) and want to pass all configuration to the mcspi controller.
The configurations like chip_select, mode, speed, bits etc., Basically all these configurations I want to use for my test driver to check functionality of FIFO mode in the mcspi. I have already enabled FIFO in the mcspi but I want to check its functionality.
Can anyone please give me some suggestions?
I don't really know why cant you do something you want. I think you can pass the configuration by set up parameters using module_param
Adding on what #sunnyleevip suggested: another "standard" way to configure your driver would be to expose the params of interest via the /proc or the /sys filesystems.
You can find all the details in Linux Device Driver
Expanding on #sergico and #sunnyleevip, you could also use device tree to pass configuration data to the driver. The SPI bus master driver (since the 2.6.30s and all of the 3.x kernels) already are pretty devicetree supportive, so there might not be much more to do to get it to work.
I have a daemon that forks the process.
This daemon access a database using mysql connector library.
When I do not fork, I am able to open and read a database fine, however, when I fork, I get
MySQL server has gone away
errors consistently on the first query...
Anyone know what could be causing this?
Edit Oh, my apologies for misinterpreting
Still the problems with differences between daemonized/non-daemonized are roughly with the following class of options:
environment variables
LIBPATH
PATH
HOME, UID, EUID (HOME surprisingly enough gets (ab)used way too often)
mysql specific variables
permissions
what user is the daemon running as? elevated or privilege separation?
current working directory (traditionally / for daemons, where / might be a chroot jail instead of 'real' /)
Starting with kernel 2.4.19, Linux provides per-process mount namespaces. A
mount namespace is the set of file system mounts that are visible to a
process. Mount-point namespaces can be (and usually are) shared between
multiple processes, and changes to the namespace (i.e., mounts and unmounts)
by one process are visible to all other processes sharing the same namespace.
(The pre-2.4.19 Linux situation can be considered as one in which a single
namespace was shared by every process on the system.)
detached stdin/stdout causing trouble (IMO that would mean badly designed library, but who am I)
watch it that specific resources (file locks, socket connections, threads (!)) are NOT inherited across fork/execve. I recommend reading the linked on daemonization (below), especially for example the section on 'Mutual Exclusion and Running a Single Copy [open,lockf,getpid]'
I'm sure I'm forgetting stuff
Ermm... what are you starting a mysql server process for? Mysql has plenty of sound init scripts that do work.
On the subject of proper daemonization: http://www.enderunix.org/docs/eng/daemon.php
Pay attention to the effects of sharing resources with fork children (e.g. file descriptors).
Besides that, you could just be missing basic environment settings. Peruse the official init scripts for mysql to find out which you need.
Is it possible to access kernel objects on remote computers? I was reading that you could access remote kernel objects by using a symbolic link to \Device\Mup\server\object but I am not sure if that would work. Thanks for the help!
I know this is a little odd but I was trying to access a named pipe.
This is not possible in the general case - Mup is the broker that chooses which remote filesystem (WebDav/SMB/NFS) to engage for a particular UNC path. What kernel objects are you trying to access specifically?
Edit: Named pipes are definitely doable - try the syntax:
\\machinename\pipe\nameofpipe
Keep in mind that the pipe has to be ACLed appropriately