[SOLVED] file open permission denied

Hello,

I am using Linux 5.15.84 running on Raspberry Pi 4B and trying to use the function open() to open /dev/mem. But got the error because of permission denied.
crw-r----- 1 root kmem 1, 1 Jan 17 21:44 /dev/mem

As /dev/mem is owned by root, is giving root permission temporarily the only way out?

At the same time, in another program, I am able to open a file in /proc. That file is also owned by root.
-rw-rw-rw- 1 root root 0 Jan 23 22:19 /proc/driver-gpio

What is the difference when use open() to open these two files?

Thanks for your help!

Crane

If you look at the permission settings, you'll see

First char = file type if any. In your case that's c (char type stream) and '-' = 'regular'

Then we have 3 groups of (potentially rwx) for user, group, other = world.

Filetypes https://www.computernetworkingnotes....-in-linux.html
File Perms https://www.computernetworkingnotes....-language.html

why do you want to do that at all?

Originally Posted by chrism01 If you look at the permission settings, you'll see First char = file type if any. In your case that's c (char type stream) and '-' = 'regular' Then we have 3 groups of (potentially rwx) for user, group, other = world. Filetypes https://www.computernetworkingnotes....-in-linux.html File Perms https://www.computernetworkingnotes....-language.html

Thank you Chris. Clear now!

Originally Posted by pan64 why do you want to do that at all?

Thank you Pan64 for raising this question. I am looking to write a user space driver and find an example which use this way to access to GPIO registers. Just want to test this method to write an user space driver.

It looks it is not a decent way to write a user space driver. Any suggestions?

Thanks!
Crane

Here is a book about it: https://www.oreilly.com/library/view...1/ch02s07.html
But actually you do not need to buy it, just read what is available:

Direct access to memory is possible only by mmapping /dev/mem, and only a privileged user can do that.

Otherwise you can find a lot of links on the net about it:
https://tldp.org/LDP/khg/HyperNews/g...ices/fake.html
https://www.kernel.org/doc/html/v5.0...uio-howto.html
(although they are old, you can start with them)
And here is something for GPIO: https://blog.lxsang.me/post/id/33

Originally Posted by pan64 Here is a book about it: https://www.oreilly.com/library/view...1/ch02s07.html But actually you do not need to buy it, just read what is available: Otherwise you can find a lot of links on the net about it: https://tldp.org/LDP/khg/HyperNews/g...ices/fake.html https://www.kernel.org/doc/html/v5.0...uio-howto.html (although they are old, you can start with them) And here is something for GPIO: https://blog.lxsang.me/post/id/33

Great stuff. Thank you so much pan64. Will start from here.

Regards,
Crane

Something else to realize is that /dev, /proc, /sys are non-existent "filesystems."

Each of these are, in fact, "Linux kernel APIs." There is absolutely nothing "physically real" about them.

And so, even though the metaphor of "directories, device-nodes and files," with associated "permission masks" and "content," has generally been retained, there might be exceptions to the rule. It is entirely up to the kernel itself. Fundamentally, they are all APIs.

Originally Posted by sundialsvcs Something else to realize is that /dev, /proc, /sys are non-existent "filesystems." Each of these are, in fact, "Linux kernel APIs." There is absolutely nothing "physically real" about them. And so, even though the metaphor of "directories, device-nodes and files," with associated "permission masks" and "content," has generally been retained, there might be exceptions to the rule. It is entirely up to the kernel itself. Fundamentally, they are all APIs.

Thank you sundialsvcs!

One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?

It means those data structures are created/maintained by the kernel & could change any time.

Originally Posted by Cranegsh Thank you sundialsvcs! One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?

Those are sometimes called virtual filesystems, they look like a filesystem. When you try to access them (like /dev/mem or /proc/<whatever> the kernel will recognize it, do something and actually will simulate a filesystem-like behavior.
(for example cat /proc/<PID>/cmdline will display the command - how the process <PID> was started, but that file actually does not exist at all).

One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?

What I literally mean is that: "this is a kernel API" (API = Application Program Interface) which merely presents itself as "files and directories." (Part of this implementation is to provide "ownership and permission-masks.") But, at the end of the day, everything that you "think you see," and everything that you can "do," is determined and implemented solely by the kernel itself.

Yes: "it is not anything like 'a normal file,' yet it perfectly appears to be."

You "ask to open, read or write a 'file' in some 'directory.'" The kernel interprets your request, decides if you can do it (and if so, just what you should see ...), and if so presents the results to you "as a 'file.'" But it is "100% an illusion." There is no physical file, and there is no directory.

"/dev, /proc, /sys ..." they don't exist. (Well, some entries in "/dev" do correspond to physical devices, but some don't.)

Personally, I think that this is a brilliant approach because, "in Unix/Linux, 'everything is a file.'" Kernel API's are often very difficult to deal with, but this one is ... elegant.

Originally Posted by sundialsvcs Personally, I think that this is a brilliant approach because, "in Unix/Linux, 'everything is a file.'" Kernel API's are often very difficult to deal with, but this one is ... elegant.

It is indeed brilliant and elegant! For comparison look at [put anything else here].

I have a better link for that device drivers book

https://lwn.net/Kernel/LDD3/

Thanks Chris, pan64, sundialsvcs, astrogeek, dugan for your reply and sharing the link.

I found this article that explains the details of /dev and /proc.
https://www.linux.com/news/using-dev...-file-systems/
It looks they are the ways to interact with the Linux kernel, not serving the purpose of access to the devices.