Device node in LXC is not accessible when connected via SSH - linux

I have a problem where a physical hardware device passed through to an LXC container cannot be read from or written to when I am connected via SSH.
The device node of my physical hardware device looks like this:
myuser#myhost:~$ ls -la /dev/usb/hiddev0
crw-rw-rw- 1 root root 180, 0 Jul 30 10:27 /dev/usb/hiddev0
This is how I create and start my container:
myuser#myhost:~$ sudo lxc-create -q -t debian -n mylxc -- -r stretch
myuser#myhost:~$ sudo lxc-start -n mylxc
Then I add the device node to the LXC:
myuser#myhost:~$ sudo lxc-device -n mylxc add /dev/usb/hiddev0
Afterwards the device is available in the LXC and I can read from it after having attached to the LXC:
myuser#myhost:~$ sudo lxc-attach -n mylxc
root#mylxc:/# ls -la /dev/usb/hiddev0
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/usb/hiddev0
root#mylxc:/# cat /dev/usb/hiddev0
����������^C
root#mylxc:/#
I then enable root access via SSH without a password:
myuser#myhost:~$ sudo lxc-attach -n mylxc
root#mylxc:/# sed -i 's/#\?PermitRootLogin.*/PermitRootLogin yes/g' /etc/ssh/sshd_config
root#mylxc:/# sed -i 's/#\?PermitEmptyPasswords.*/PermitEmptyPasswords yes/g' /etc/ssh/sshd_config
root#mylxc:/# sed -i 's/#\?UsePAM.*/UsePAM no/g' /etc/ssh/sshd_config
root#mylxc:/# passwd -d root
passwd: password expiry information changed.
root#mylxc:/# /etc/init.d/ssh restart
Restarting ssh (via systemctl): ssh.service.
root#mylxc:/# exit
When I connect via SSH now, the device node is there, but I cannot access it:
myuser#myhost:~$ ssh root#<lxc-ip-address>
root#mylxc:~# ls -la /dev/usb/hiddev0
crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/usb/hiddev0
root#mylxc:~# cat /dev/usb/hiddev0
cat: /dev/usb/hiddev0: Operation not permitted
In both cases (lxc-attach and ssh) I am the root user (verified via whoami), so this cannot be the problem.
Why am I not allowed to access the device when I am connected via SSH?
EDIT
In the meantime I found out that the error disappears when I call all the LXC initialization commands directly one after another in a script, i.e.:
sudo lxc-create -q -t debian -n mylxc -- -r stretch
sudo lxc-start -n mylxc
sudo lxc-device -n mylxc add /dev/usb/hiddev0
...
And then all the SSH configuration as described above. The device is correctly accessible via SSH then.
As soon as some time passes between lxc-start and lxc-device, the error appears, e.g.:
sudo lxc-create -q -t debian -n mylxc -- -r stretch
sudo lxc-start -n mylxc
sleep 1
sudo lxc-device -n mylxc add /dev/usb/hiddev0
...
Why is the timing relevant here? What happens during the first second within the LXC that makes the device become unaccessible?

With help from the lxc-users mailing list I found out that the restriction is intended. Access to devices has to be allowed explicitly in the LXC's config using their major/minor numbers:
lxc.cgroup.devices.allow = c 180:* rwm
The unrestricted access using lxc-attach seems to be some bug in my case. Devices should never be accessible in the LXC if not explicitly allowed.

Related

systemd service: Failed to execute command: Permission denied

I am trying to run an SSH command in a systemd service. Although I the user I set to run the command fedora has permission to everything the command requires (verified by both running the command manually in a logged-in shell without failure and permission checks on the files), it still gives the error of permission denied.
[Unit]
Description=AutoSSH tunnel
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/ssh -f -TN -L 3333:localhost:3333 -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 60" -i /home/fedora/.ssh/id_rsa ubuntu#server
ExecStop=/usr/bin/pkill -f 3333:localhost:3333
Restart=always
RestartSec=10
User=fedora
Group=fedora
[Install]
WantedBy=multi-user.target
error message:
Oct 16 11:10:47 Lenovoserver systemd[2318595]: autossh-tunnel.service: Failed to execute command: Permission denied
Oct 16 11:10:47 Lenovoserver systemd[2318595]: autossh-tunnel.service: Failed at step EXEC spawning /usr/bin/ssh: Permission denied
Permission checks:
-rwxr-xr-x. 1 root root 808832 Oct 9 2019 /usr/bin/ssh
fedora user has permission to execute /usr/bin/ssh
-rw-------. 1 fedora fedora 2610 Jan 3 2020 /home/fedora/.ssh/id_rsa
fedora user has read access to its private key.
Did I do anything wrong or is this a systemd bug?
It could be SELinux, the new ssh port has to be registered in selinux.
Firs check if the service work by disabling selinux temporarily, if it works add ssh port to selinux as follow.
# Check selinux status
sestatus
# Disable selinux temporarily
setenforce 0
# Check selinux ssh port
semanage port -l | grep ssh
ssh_port_t tcp 22
# Add selinux ssh port
sudo semanage port -a -t ssh_port_t -p tcp 3333
# Check selinux ssh port
semanage port -l | grep ssh
ssh_port_t tcp 22, 3333

sshpass Failed to Get a Pseudo Terminal in Windows 10 ubuntu linux bash

Has anyone tried using sshpass in a windows 10 insider preview linux terminal?
It just returns this error
root#T430U:~# sshpass -p mypass ssh user#host
Failed to get a pseudo terminal: No such file or directory
Like it says here. You have to mount the pts directory:
m -rf /dev/ptmx
mknod /dev/ptmx c 5 2
chmod 666 /dev/ptmx
umount /dev/pts
rm -rf /dev/pts
mkdir /dev/pts
vim /etc/fstab
(added: none /dev/pts devpts defaults 0 0)
mount /dev/pts

QEMU: /bin/sh: can't access tty; job control turned off

As a development environment for linux kernel, I'm using qemu with setting up initramfs as similar to what is shown here, with few additional executable. Basically, it uses busybox for creating minimal environment and package it up using cpio. Content of init is shown below.
$ cat init
mount -t proc none /proc
mount -t sysfs none /sys
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
exec /bin/sh
Using following command to start VM:
qemu-system-x86_64 -kernel bzImage -initrd initramfs -append "console=ttyS0" -nographic
It throws following error:
/bin/sh: can't access tty; job control turned off
Although, system functions normal in most cases. But, I'm not able to create background process:
$ prog &
/bin/sh: can't open '/dev/null'
$ fg
/bin/sh: fg: job (null) not created under job control
Root of all problems seem to be not having access to tty. How can I fix this?
EDIT: Apart from Accepted answer, as a get around cttyhack of busybox can be used.
$cat init
#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mknod -m 666 /dev/ttyS0 c 4 64
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
setsid cttyhack sh
exec /bin/sh
From Linux From Scratch Chapter 6.8. Populating /dev
6.8.1. Creating Initial Device Nodes
When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. Create these by running the following commands:
mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
You should then continue with the steps in "6.8.2. Mounting tmpfs and Populating /dev". Note the <-- below, and I suggest you read the entire free LFS.
mount -n -t tmpfs none /dev
mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
mknod -m 666 /dev/ptmx c 5 2
mknod -m 666 /dev/tty c 5 0 # <--
mknod -m 444 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
chown root:tty /dev/{console,ptmx,tty}

Can not add new user in docker container with mounted /etc/passwd and /etc/shadow

Example of the problem:
docker run -ti -v my_passwd:/etc/passwd -v my_shadow:/etc/shadow --rm centos
[root#681a5489f3b0 /]# useradd test # does not work !?
useradd: failure while writing changes to /etc/passwd
[root#681a5489f3b0 /]# ll /etc/passwd /etc/shadow # permission check
-rw-r--r-- 1 root root 157 Oct 8 10:17 /etc/passwd
-rw-r----- 1 root root 100 Oct 7 18:02 /etc/shadow
The similar problem arises when using passwd:
[root#681a5489f3b0 /]# passwd test
Changing password for user test.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: Authentication token manipulation error
I have tried using the ubuntu image, but the same problem arises.
I can manually edit passwd file and shadow file from within container.
I am getting the same problem on following two machines:
Host OS: CentOS 7 - SELinux Disabled
Docker Version: 1.8.2, build 0a8c2e3
Host OS: CoreOS 766.4.0
Docker version: 1.7.1, build df2f73d-dirty
I've also opened issue on GitHub: https://github.com/docker/docker/issues/16857
It's failing because passwd manipulates a temporary file, and then attempts to rename it to /etc/shadow. This fails because /etc/shadow is a mountpoint -- which cannot be replaced -- which results in this error (captured using strace):
102 rename("/etc/nshadow", "/etc/shadow") = -1 EBUSY (Device or resource busy)
You can reproduce this trivially from the command line:
# cd /etc
# touch foo
# mv foo shadow
mv: cannot move 'foo' to 'shadow': Device or resource busy
You could work around this by mounting a directory containing my_shadow and my_passwd somewhere else, and then symlinking /etc/passwd and /etc/shadow in the container appropriately:
$ docker run -it --rm -v $PWD/my_etc:/my_etc centos
[root#afbc739f588c /]# ln -sf /my_etc/my_passwd /etc/passwd
[root#afbc739f588c /]# ln -sf /my_etc/my_shadow /etc/shadow
[root#afbc739f588c /]# ls -l /etc/{shadow,passwd}
lrwxrwxrwx. 1 root root 17 Oct 8 17:48 /etc/passwd -> /my_etc/my_passwd
lrwxrwxrwx. 1 root root 17 Oct 8 17:48 /etc/shadow -> /my_etc/my_shadow
[root#afbc739f588c /]# passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root#afbc739f588c /]#

Linux permissions issue on sftp server

Good day!
I have a linux sftp server located in VM. This VM has access to a GlusterFS storage, where sftp directories are located. Sftp works via OpenSSH server and chroots sftpusers group to sftp directories on GlusterFS storage. All worked well... After one moment I had got an issue...
Trying to create user:
# useradd -d /mnt/cluster-data/repositories/masters/test-user -G masters,sftpusers -m -s /bin/nologin test-user
Checking:
# cat /etc/passwd | grep test-user
test-user:x:1029:1032::/mnt/cluster-data/repositories/masters/test-user:/bin/nologin
# cat /etc/group | grep test-user
masters:x:1000:test-user
sftpusers:x:1005:test-user
test-user:x:1032:
Doing chown and chmod for home dir by hand:
# chown -R test-user:test-user /mnt/cluster-data/repositories/masters/test-user
# chmod -R 770 /mnt/cluster-data/repositories/masters/test-user
Checking:
# ls -la /mnt/cluster-data/repositories/masters/test-user
итого 16
drwxrwx--- 2 test-user test-user 4096 Окт 27 2013 .
drwxr-xr-x 13 root masters 4096 Окт 27 2013 ..
Adding another user to test-user's group:
# usermod -G test-user -a tarasov-af
# cat /etc/passwd | grep tarasov-af
tarasov-af:x:1028:1006::/mnt/cluster-data/repositories/lecturers/tarasov-af/:/bin/nologin
# cat /etc/group | grep tarasov-af
masters:x:1000:tarasov-af,test-user
sftpusers:x:1005:tarasov-af,test-user
lecturers:x:1006:tarasov-af
specialists:x:1008:tarasov-af
test-user:x:1032:tarasov-af
Login as tarasov-af:
sftp> cd masters/test-user
sftp> ls
remote readdir("/masters/test-user"): Permission denied
sftp> ls -la ..
drwxr-xr-x 13 0 1000 4096 Oct 26 21:30 .
drwxr-xr-x 6 0 0 4096 Oct 2 15:53 ..
drwxrwx--- 2 1029 1032 4096 Oct 26 21:53 test-user
I tried to login as tarasov-af into bash (usermod -s /bin/bash tarasov-af):
$ id
uid=1028 gid=1006
groups=1000,1005,1006,1008,1032
p.s. I guess this issue began after VM disk failed and I've got /etc/passwd and /etc/group broken, I've restored them from backups and all previous accounts works well, I have this issue only with new accounts.
I've found the reason of this issue: user tarasov-af has more than 16 secondary groups, first 15 groups work good, other -- don't work. I've set kernel.ngroups_max = 65535 in sysctl.conf on every computer in cluster (GlusterFS) and on sftp VM but nothing changed.
This issue goes to glusterfs client, it can't manipulate with more than 15 secondary groups.
# glusterfs --version
glusterfs 3.2.7 built on Sep 29 2013 03:28:05

Resources