Problem with chardev.c example from The Linux Kernel Module Programmers Guide - linux

I compiled and ran the chardev.c example from the lkmpg and when writing to the device received an unexpected error:
anon#anon:~/lkmpg$ sudo echo "hi" > /dev/chardev
bash: /dev/chardev: Permission denied
The module write function looks like this:
/*
* Called when a process writes to dev file: echo "hi" > /dev/chardev
*/
static ssize_t
device_write(struct file *filp, const char *buff, size_t len, loff_t * off)
{
printk(KERN_ALERT "Sorry, this operation isn't supported.\n");
return -EINVAL;
}
I'm not getting the expected error of invalid operation and the error printed to /var/log/messages.
I can read from the device with no problem, receiving the expected results:
anon#anon:~/lkmpg$ cat /dev/chardev
I already told you 6 times Hello world!
The device /dev/chardev is created manually using:
sudo mknod /dev/chardev c 252 0
What's the deal?
--Edit--
Apparently when I mknod to create the device it ends up with the following permissions:
crw-r--r-- 1 root root 252, 0 2009-10-30 09:27 /dev/chardev.
Once I did sudo chmod a+w /dev/chardev the driver worked as expected.
However, people have said it is not correct to do this.
What is the correct course of action and why?

A really, really, really straight forward and simple example of how to implement character drivers can be found in drivers/watchdog/softdog.c
You can compare your code to this example, which shows you how to do the following:
Read from the device
Write to the device
Present an ioctl interface via the device
While softdog is a very useful tool, its as much a tutorial as anything else. Alan Cox threw it together, so its a good example of more 'proper' implementation.
If you can post the whole source to your module, we can help you find out why your function is not being entered as expected.
Update:
It is perfectly acceptable to allow under privileged users to write to character devices! I repeat, it is perfectly acceptable to allow under privileged users to write to character devices! If this was not the case, stuff like FUSE, Modems, USB Gadgets, CD ROMS and other things would require root access to use.
What you can do is take advantage of group memberships. I.e., on Ubuntu, users permitted to use FUSE (file system in user space) should belong to the 'fuse' group, which permits granular access on who can and can not use that feature. Similarly, on some of my systems, a QRNG (quantum random number generator) is in use .. and is (you guessed it) a character device. I need to allow PHP to access that device , so I:
Create a QRNG group
Make sure PHP runs as the user (not anonymous system users)
Add users owning apps that need access to the device to the QRNG group
I hope that clears it up :)

I think, actual problem is the command which you issued to write is incorrect. Try
#sudo sh -c "echo "hi" > /dev/chardev"
If you want to run multiple commands with sudo then you should use command as shown above. With this, you dont need to do chmod and change its permissions as well. Hope this helps.

Related

PWM without sysfs

I am pretty new to linux kernel.I am trying to generate PWM through linux. The API man talks about a sysfs interface. I want to implement a userspace program in C. But using PWM forces me to use a command line. Furthermore, using read, write is a problem in C as when I am using cd, it is changing path directory.
Thus the path is variable. Is there any way I can pass values to pwm_config() without using sysfs? Perhaps through ioctl? If yes, then what would be the procedure?
Application C code:
void main(){
int export = open("/sys/class/pwm/pmwchip0/export",O_WRONLY);
int period,duty_cycle,enable;
if(export == -1)
{
perror("Export:");
}
and so on for other files like period and duty cycle.
When I try to run my application I get the following error.
Export:: No such file or directory
Export_write: Bad file descriptor
Period_write:: Bad file descriptor
Duty_cycle_write:: Bad file descriptor
Enable_write:: Bad file descriptor
As far as I know, the sysfs is the only standard userspace interface to PWM. But anything you can do from the command line can be done in C (the shell is written in C, after all).
The problem you are having with cd is not actually a problem. Inside sysfs the directories in /sys/class/pwd/* are actually symbolic links to the proper devices. In your case /sys/class/pwm/pwmchip0 is a symlink to /sys/devices/soc0/amba/f8001000.timer/pwm/pwmchip0.
The funny thing is that some shells, when you cd a symbolic link will resolve to the real directory, but other shells will actually keep the symlink name as the current directory.
But that issue with the directory symlinks should not be an issue for you. A C program willing to manage PWM devices should not change the working directory. Instead open the files with the full path:
open("/sys/class/pwm/pwmchip0/npwm", O_RDONLY);
and so on.

Open file by inode

Is it possible to open a file knowing its inode?
ls -i /tmp/test/test.txt
529965 /tmp/test/test.txt
I can provide path, inode (above 529965) and I am looking to get in return a file descriptor.
This is not possible because it would open a loophole in the access control rules. Whether you can open a file depends not only on its own access permission bits, but on the permission bits of every containing directory. (For instance, in your example, if test.txt were mode 644 but the containing directory test were mode 700, then only root and the owner of test could open test.txt.) Inode numbers only identify the file, not the containing directories (it's possible for a file to be in more than one directory; read up on "hard links") so the kernel cannot perform a complete set of access control checks with only an inode number.
(Some Unix implementations have offered nonstandard root-only APIs to open a file by inode number, bypassing some of the access-control rules, but if current Linux has such an API, I don't know about it.)
Not exactly what you are asking, but (as hinted by zwol) both Linux and NetBSD/FreeBSD provide the ability to open files using previously created “handles”: These are inode-like persistent names that identify a file on a file system.
On *BSD (getfh and fhopen) using this is as simple as:
#include <sys/param.h>
#include <sys/mount.h>
fhandle_t file_handle;
getfh("<file_path>", &file_handle); // Or `getfhat` for the *at-style API
// … possibly save handle as bytes somewhere and recreate it some time later …
int fd = fhopen(&file_handle, O_RDWR);
The last call requiring the caller to be root however.
The Linux name_to_handle_at and open_by_handle_at system calls are similar, but a lot more explicit and require the caller to keep track of the relevant file system mount IDs/UUIDs themselves, so I'll humbly link to the detailed example in the manpage instead. Beware, that the example is not complete if you are looking to persist the handles across reboots; one has to convert the received mount ID to a persistent filesystem identifier, such as a filesystem UUID, and convert that back to a mount ID later on. In essence they do the same however. And just like on *BSD using the later system call requires elevated privileges (CAP_DAC_READ_SEARCH to be exact).

How to differentiate a linux command execution from command line and a program

I have a unix command 'abc' which gives me an output
This abc lies on my server.
But when i run this command from server, i want to restrict the output of it to be seen by people.
By the above statement , i meant..
For eg. If i say:
ls dirname
I can see the output of the above command on the console.
So, if the command is run from command-line, i dont want to have echoed on the console. I cant use /dev/null as I am using the same command from my program where I need the output to be assigned to a variable and then use it further in my application.
However, I want to get the output of this command when I call this from my program.
How can I differentiate the call in this regard.
The command whoami gives you the current logged user, and the command last -i outputs information of the last logged users in the system, including the IP address (3rd column) and the timestamp or a string stating that the user is stil logged in.
With that in mind you could pipe these commands:
last -i | grep $(whoami) | grep 'still logged in'
which will provide an output like this:
(username) pts/2 0.0.0.0 Wed Dec 23 18:58 still logged in
(username) :0 0.0.0.0 Wed Dec 23 11:13 still logged in
so if you are running a shell in the same host, the IP will be 0.0.0.0 and different otherwise. You can extract the IP string by piping awk at the end of the command.
However, addhering to the philosophy in unix systems of Do One Thing and Do It Well, I'd suggest a different approach, split your command into 2 different commands:
A command to be used by the clients, where the output is whatever you
want the clients to see
Another command (offering 2 options, since there isnt much detail in the question):
Either extending the first command, adding the additional output, and using this one from your application
Or just generating the additional output, and using a combination of the 2 commands from your application
Some of the benefits you can get by following this approach:
Performing checks to verify where the command was issued from, is no longer necessary
Avoid coupling issues
Easier to maintain
Updated: added the means to extract the IP of the current user at the beggining of the answer.
You were a little vague on the complete setup, so I'll have to infer a few things. Since you mentioned, "my" server, I assume you can set permissions on files, change ownership on files, etc (e.g. you can become root).
I also have to infer that the target abc program just produces some output and doesn't need to modify any files to speak of [other than (e.g.) /tmp/temp.$$]
As an example, let's do this from your home directory. Move the program abc to $HOME/private_bin and set the directory permission to 700 which means that only you can execute it.
Create a second directory: $HOME/public_bin that has normal permissions. Create a "launcher" program [let's call it abcpub] and put it in this directory. Set the permissions of abcpub to 4741. It's now a setuid program. Note that any non-root user may do this for files they own. It is not like creating a sudo because an ordinary user would need to do chown root ...
Now we're set ...
You can access the real abc program anytime you want. Others have no direct access to abc.
The launcher abcpub will allow others to have access to abc, but the launcher can apply whatever restrictions you desire: including no access, output to /dev/null, etc. abcpub can look at getuid and geteuid to determine who is executing it [you or somebody else]
We did the above example using your own uid and home directory. But, we can repeat the process by creating an "abc" user in /etc/passwd and a /home/abc. The abc user could be set up with a shell of /sbin/nologin. Thus, it's similar to nobody and it can't hurt anything.
It may be even better doing this by creating a setgrp program instead of setuid as that allows better comingling. The original user could retain their user permissions but still get access via the new group.
Also, it may be possible to configure sudo to get what you want.

Automate Bluetooth Pairing/Trusting in Bluez5

I've been working on making my RPi 2 function like a car bluetooth receiver and all is well, except I have no idea how I could automate the pairing of bluetooth devices in Bluez5. In the past I would've used the bluetooth agent and a simple script, but that seems to have gone out the window with the move from 4 -> 5. The nature of the setup means I have no kb/mouse on the RPi once its in the car, so it needs to be a fully automated setup where anyone can scan for the RPi, and if the probably hard-coded PIN is correct, the trusting of the device needs to be automatically done, no cli input.
I've searched all over the web but everyone seems to say that using bluetoothctl works for them, but in this particular setup where I'd like to be able to have friends pair their own phones, having to trust devices with the RPi out of the car isn't ideal.
I'm not sure why you say using a simple script is not possible with bluez5. I think you can do it. Below is one example how.
Download the bluez5 source and edit test/simple-agent. Comment out the lines of code as shown below:
def RequestAuthorization(self, device):
print("RequestAuthorization (%s)" % (device))
#auth = ask("Authorize? (yes/no): ")
#if (auth == "yes"):
return
#raise Rejected("Pairing rejected")
What that does it remove the prompt for authorisation and always accepts the pairing request.
Can now start the simple-agent with the NoInputNoOutput capability so that it uses simple pairing and will go through the above code path:
./simple-agent -c NoInputNoOutput
After that you should be able to pair with the RPi without any user prompt or PIN.
Note that this is just one example of what you can do. If say you wanted to have a hard coded PIN instead of simple pairing then edit the appropriate section of the same simple-agent code to do that. I'll leave that as an exercise for you.
I already had bluez-5.43 installed. This is how to automate the pairing process on a raspberry pi.
(1) First test a line like this out to make sure bluetooth agent works:
bluez-5.43/test/simple-agent -c NoInputNoOutput
(2) To automate pairing, put this code into a shell file (I named mine pairbot.sh):
if [ "$(id -un)" != "pi" ]; then
exec sudo -u pi $0 "$#"
fi
export XAUTHORITY=/home/pi/.Xauthority
export DISPLAY=:0
lxterminal --command="/bin/bash -c '/home/pi/bluez-5.43/test/simple-agent -c NoInputNoOutput &; read'"
(3) Go to crontab:
sudo cronetab -e
(4) At the bottom add:
#reboot sleep 20 && /home/pi/pairbot.sh > /home/pi/blelog.txt 2>&1
(5) Reboot and test if it works.
My recommendation for others facing the same issue would be to look into your bluez folder (or if you don't have one install the latest version of bluez) and search for the folder that says "test" for "simple agent" to locate the file path. From here, you should be able to construct the command line shown above (1). Hopefully it will work for you too.

Linux: device appears in /dev but cannot be accessed

I have created a Linux device driver and can add it to the system (insmod, mknod). When I look in /dev I see it listed as camerax:
ls -l /dev/camerax
crw-r--r-- 1 root root 245, 0 Jun 27 17:19
Even so, I cannot access it. Whatever I do, I get an error.
For example:
int fd = open("/dev/camerax", O_RDONLY);
printf("%d [%s]\n", fd, strerror(errno));
Generates:
-1 [No such device or address]
I'm running as a super user. Any suggestions?
Your Module is not linked to the special file which you have mentioned so it is giving error.
If your module is successfully inserted verify in /proc/devices using cat command
cat /proc/devices.
file created using mknod in the path /dev/____ is just a refrence to your driver
The major and minor number should match with your inserted device.
I have solved the problem.
Instead of creating the major device number dynamically, as described in the documentation, I now set it explicitly to 61. Everything now works.
The only difference I can see between the working and non-working versions is the major number (and yes, I change anything that uses the device number so I am always using the appropriate one).
This adds one more bizarre feature of the system to my growing list.

Resources