I want to get number of RAM slot (DIMM) and CPU socket of a PC in Linux.
In Linux, there's a command dmidecode but this command must run with sudo/root permissions.
Anyone can tell me another solution to get DIMM & CPU socket without using sudo/root permissions.
The only thing that has information is the SMBIOS / DMI, and the only way to get access to this is via /dev/mem.
If you're concerned with a user having too much privilege with sudo, then you can add the specific permission to run dmidecode by a particular user:
example stub from the sudoers file:
# Cmnd alias specification
Cmnd_Alias DMI_COMMANDS = /usr/sbin/dmidecode -t memory
dmiuser ALL= NOPASSWD: DMI_COMMANDS
This allows the dmiuser account to execute only the command dmidecode -t memory (without a password in this case).
Related
I'm working on Linux Kernel 3.14.28 build with Buildroot for an embedded device.
In /dev/, all ttys are root:root and not root:dialout like a standard Linux. So it is not possible to access any ttyX without being logged as root.
How can I change the tty group permanently to root:dialout? I try to change it with chown command, but it became root:root again on reboot.
TL;DR: choose mdev as your device manager, and use the tty group instead of dialout.
The kernel's devtmpfs creates device nodes with a default name, owner and permissions. It also sends out a uevent when the node is created, which allows a uevent handler to change the name, ownership or permissions, or do anything else it wants. Previously this was called the hotplug system, but nowadays it's much more generic.
Buildroot offers the choice between three uevent handlers: mdev, which is part of busybox, eudev which is a standalone udev fork, and udev which is part of the systemd init system. These handlers are configured with rules files that specify what to do with a specific type of device when it appears.
For your specific need, mdev is the best choice since it is very simple, easy to understand, doesn't take up much space, and the default configuration is sufficient. In Buildroot's menuconfig, go to System configuration → /dev management and select Dynamic using mdev. Then rebuild your root filesystem. It will now be populated with the mdev binary (part of busybox), an init script to start it, and a default rules file in /etc/mdev.conf. This default file contains:
tty[0-9]* root:tty 660
This means that the tty devices will get their group changed to tty and their permissions to group read and write. So you can just make sure that the logged in user belongs to the tty group, and Bob's your uncle.
If the default mdev.conf file is not sufficient for you (for instance, if you really need the group to be dialout), then you can create a filesystem overlay, copy package/busybox/mdev.conf to /etc/mdev.conf and modify it as needed. Full documentation on the mdev.conf format can be found in the busybox sources.
devtmpfs always sets permissions to 0600 and makes it up to udev (or whatever runs after it) to maintain them. Its source confirms there's no way to override this explicitly (tty device driver overrides mode unconditionally in some cases).
Assuming you're using the Buildroot's default busybox as init, there's a way to do this with the following additional line in busybox's inittab (additional=must be present in addition to the essential lines (or their replacements) that are implied when there's no inittab - as they are no longer implied then there is):
::sysinit:<path_to_your_script>
with the script calling chown and chmod in loop.
But, it's better to handle this within the existing /etc/init.d/rcS (which is also run by BusyBox's init at sysinit by default).
As you can see from the stock buildroot's /etc/init.d/rcS, all you need to do is create a script /etc/init.d/S<whatever>.sh (where "whatever" places it into the desired position in the /etc/init.d/S??* output) with your commands:
for tty in /dev/tty*; do
chown root:dialout "$tty"
chmod ug+rw "$tty" #do not touch other bits
done
unset tty
I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh myusername#IP_ADDRESS
On the server:
sudo su
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open /dev/tty for read-write and prints that error if it fails. You've indicated in comments that /dev/tty is missing on your system.
Sudo has an option -S to read the password from standard input instead of /dev/tty. You should be able to run sudo -S to become root.
Regarding how to recover /dev/tty, It's possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I'd inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where "major" is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You've to either log-in as root or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes "have a tty". If you are still having problems, it's probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command "tty" - if it returns "not a tty", that shell doesn't have a "controlling tty" and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) -- High Sierra uses a different mechanism for allocating pty's than earlier Mac OS X releases, so if your code isn't reconfigured for it, it will fail to allocate a pty.
I have Linux server (CentOS release 6.4) which is able to process source code sent by users. On the server is a Java application which starts a bash script which will run compilation and execution commands of these source codes in a limited way (time and memory are limited, no Internet, executed by limited user).
The Java program must be always be running, so it can register new job requests.
When started, the Java program works fine, but after some time (talking in days), commands are not executed properly. I get the following error message:
sudo: sorry, you must have a tty to run sudo
the line which is causing that is:
sudo -u codiana $COMMAND &
where $COMMAND is command to execute along with its arguments
After application restart (kill and start again) everything works.
Is there some time limit on Linux which can cause that?
You can comment /etc/sudoers:
#Defaults requiretty
Edit:
man sudoers | grep requiretty -A 5
requiretty If set, sudo will only run when the user is logged in
to a real tty. When this flag is set, sudo can only be
run from a login session and not via other means such
as cron(8) or cgi-bin scripts. This flag is off by
default.
So if this is not desired open /etc/sudoers with you text editor of choice and comment out this line.
Can someone help me to understand how I need to configure buildroot, so that I will be able to successfully boot my own file system and login to it ?
I have a (seemingly) working kernel, and now I created my own file system (didn't change any settings in build root really, except set console to ttyAMA0), but the boot process just seems to hang without any problems to this:
....
[ 3.130000] VFS: Mounted root (ext3 filesystem) on device 179:2.
[ 3.140000] Freeing init memory: 144K
Starting logging: OK
Starting network...
ip: RTNETLINK answers: Operation not permitted
ip: SIOCSIFFLAGS: Permission denied
Whole boot log is visible here: http://paste.ubuntu.com/1364407/
I understand that /etc/inittab controls the boot process, the contents looks like this:
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -o remount,rw / # REMOUNT_ROOTFS_RW
null::sysinit:/bin/mkdir -p /dev/pts
null::sysinit:/bin/mkdir -p /dev/shm
null::sysinit:/bin/mount -a
null::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# Put a getty on the sttyAMA0::respawn:/sbin/getty -L ttyAMA0 115200 vt100 # GENERIC_SERIAL
# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot
# Stuff to do before rebooting
null::shutdown:/etc/init.d/rcK
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a
Any advice on what is wrong in my configuration ?
Any tips on where I could get a good overview of "the usual necessary configurations" needed when creating my own linux system ?
This problem was raised by the submitter on the Buildroot mailing list. The solution was that the submitter was using Buildroot the contents of output/target directory directly as its root filesystem, even though the Buildroot documentation explicitly tells not to do so. This is because Buildroot does not run as root, and therefore cannot create device files or adjust permissions/ownerships properly in output/target. These steps are done when creating the root filesystem images, thanks to a magic tool called fakeroot.
Therefore, if someone wants the root filesystem to extract on a SD card partition or something like that, one should ask Buildroot to generate a tar image, and then extract it as root in the SD card partition.
Since this problem was quite common, we have now added a file in output/target called THIS_IS_NOT_YOUR_ROOT_FILESYTEM which contains details about this issue. See http://git.buildroot.net/buildroot/commit/?id=9226a9907c4eb0fffab777f50e88b74aa14d1737.
I'm writing a QT application which has a shutdown button. I want to shutdown system with this button but when I use the shell command "shutdown -h now" the system asks for password.
I want to shutdown without password.
My QT code is:
QObject *parent;
myProcess = new QProcess(this);
QString command= "sudo shutdown";
QStringList arguments;
arguments << "-h " << "now" ;
myProcess->start(command,arguments);
Ensure that the user running the process is in the sudoers file.
Use visudo to alter the sudoers file and add something like the following:
<username> ALL = NOPASSWD: /sbin/shutdown
hth
Look at going through gksudo/kdesudo for calling reboot, one of those should be on most Linux installations.
They're simple wrappers that will ask the user for their password to confirm elevating privileges to root and, in your case, calling reboot or shutdown.
Just play nice with the rest of the system and let shutdown ask the user for his password.
Instead of calling a shell command you can call reboot directly to halt or reboot the system. See "man 2 reboot". But you will still get a permission error if the user does not have the CAP_SYS_BOOT capability. With sudo or suid binary, as described in the comment above, you will get this capability (and more).
You can also set the CAP_SYS_BOOT capability for your binary with the setcap program or similar. Remember that this will have to be done after each time the program is recompiled, and you have to use sudo to use setcap.