I am working on Linux 3.14.28, build with buildroot for an embeded system.
How can I read the file /sys/devices/i2c.4/i2c-1/1-0052/eeprom without root privilege?
Is there a solution to permanently change permission instead of changing it on each reboot of Linux with a script.
I'm not using udev but static table. I easily manage to change permission:
using device_table_dev.txt for /dev files
using device_table.txt for /home/files
But it has no effect on /sys/devices/i2c.4/i2c-1/1-0052/eeprom
First and foremost, don't use static table. It really doesn't make any sense to not use devtmpfs these days, unless you're using a kernel older than 2.6.32.
Then, the device table is about changing permission of files in /dev. The permission of files in /sys is directly controlled by the kernel itself.
You need to adapt the permissions of the i2c bus device file /dev/i2c-*, not the eeprom file in /sys.
Using udev following rule should do the job:
KERNEL=="i2c-[0-9]*", GROUP="dialout"
Generally something similar should be also possible with static table as you can handle /dev/i2c-* like every other /dev/* file.
Related
We are a hardware vendor and want to provide support for linux.
This means we want to provide a (user space) shared library that can be used by our customers applications without struggling with the lowlevel protocol.
Our Hardware is accessed via USB/HID and thus our library need to get access to /dev/hidrawX.
But to get access to this device (or other kind of hardware devices) it seems that we need to modify the system by adding permissions to the udev system (see
Get access to USB device on Linux (libusb-1.0)?).
Is this really best practice? If so, where should I do this? In the .deb/.rpm/... installer of the customers application? What about FlatPak or similar concepts?
Udev is standard and best practice. Every linux distribution has udev rules files typically for ex in case of ubuntu it is found in /etc/udev/rules.d folder. You need to create a udev rule file and write MODE="0666" rule to it. Take a look at this example for how to write udev rule.
I just want to show root directory and external mounted drivers (USB, CD) if available on Linux as multiple QTreeViews. As following
/
USB
CD
But, for now I can only show external mounted drivers under root directory.
You will have to build your own QAbstractItemModel (and not use QFileSystemModel) as QFileSystemModel will show you the tree files as they are.
If you are a beginner I strongly advise you to think differently your user interface as making tree model is not an easy task.
Or you can use several QFileSystemModel that would be initialized with different paths with QFileSystemModel::setRootPath :
one the VFS root
one for /media (you can even extract all mount point here /proc/mounts or use the /sys interface)
and so on.
External drives can not be viewed on Linux with QFileSystemModel
from Qt Manual:
QDir::Drives List disk drives (ignored under Unix).
First off, my intention is to create a portable, bootable USB drive containing a GNU/Linux distribution. Specifically, I want to use Arch Linux with a squashfs read-only root filesystem.
The squashfs image is based on a snapshot of a working VM. The base system with it's services like ssh work out of the box as expected. But when trying to launch gnome via systemd (systemctl start gdm), all I see is a black screen (supposedly the X-Server started but gdm fails to load). I already tried to figure out whats happening, but failed to identify the exact problem.
Home directories are writeable
/tmp is writeable
/var/log is writeable
/var/run & /run are writeable anyway
/var/log/gdm gets created but stays empty.
Which modules may require write access to any other files? Is there any documentation? What would make sense to strace or similar?
My desire is to know the root of the problem and fix it, instead of using workarounds like unionfs. Thanks for any help or hints!
Although it's not relevant, for those who might wonder why I want to do this, here are some points to consider:
Stability - as you cannot modify system files, you cannot mess up the system (unless you write bogus directly to the drive of course)
Storage - as files are compressed, more data fits on the drive
Performance - as I/O on most USB drives is slow, compression gives you higher I/O speed
Portability - no special treatment for read-only storage, you might copy it on a CD or any other read-only technology and it will still work the same way as it would on a writeable disk
Update
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
journalctl was the debugging command i was missing in the first place.
I am working on an embedded Linux platform. In our platform there is only root user. Now we want to bring in security options like
1. Low Privileged user.
2. Allowing to run only executables from a particular location(only read permission).
3. Use Linux Containers
We have managed to add a low privileged user using the /etc/passwd file. But I have no idea how to do the rest. Is there any better options to implement security in the linux system. Any documentation or links are much appreciated.
Option two is achieved by the noexec flag on mounting. The slight challenge is figuring out exactly what to mount where; you'd want to mount / as noexec to get safety by default, but you need /sbin/mount to be executable. But you can probably make / read-only and mount all the writeable filesystems as noexec.
Is it possible to mount a ISO image from USB disk and to use it as a filesystem at boot time(with grub)? I ask it because I would like to put the kernel linux image and an ISO to be used as a filesystem(with fedora bootstrap) into an USB disk(without creating new partitions, etc.), as it is possible to do by using Qemu, for example.
Qemu is a virtualization/emulation environment. Grub is a bootloader, designed to get a kernel loaded into memory and start it executing. Neither program is directly related to your question, although you could certainly use Qemu to execute a VM that uses Grub to start Linux to do what you want.
Modern Linux distributions create an initrd, which the bootloader puts into memory for the kernel to use as its initial root file system. The initrd does things like loading the modules necessary to access the hard disks where the real root file system lives. In your case, you should look at having the initrd find your ISO, mount it, and use it as the root.
The contents of initrd vary based on what distro you're using. I'd grab a livecd from somewhere, dump its initrd's contents with zcat /boot/initrd-2.6.whatever.img | cpio -id, and check out what it's doing. Look for the init file, which will be the first user-space process run by the kernel.
Grub's loopback feature should allow you to boot a kernel and initrd from within an ISO image. Unfortunately, there's no way to allow the kernel to mount a loopback device as the root filesystem, so I think you're out of luck.