user2149308's questions

I stumbled on something odd. Samba seems to require read permissions on the filesystem on a target folder if I want to move a file to it (not for copying). This goes across Samba versions (2 tested) and underlying file systems (local filesystem with ext4, nfs mount).

Is there some way to get rid of this restriction?

Test case:

Create directory structure as root

su - root
mkdir -p /tmp/samba_test/write_only
chmod 777 /tmp/samba_test
chmod 773 /tmp/samba_test/write_only

Verify directory structure

find /tmp/samba_test -exec ls -ald {} \;
drwxrwxrwx 3 root root 4096 Dez  9 12:44 /tmp/samba_test
drwxrwx-wx 2 root root 4096 Dez  9 12:17 /tmp/samba_test/write_only

Create file as unpriviledged user (access as others)

touch /tmp/samba_test/file
find /tmp/samba_test -exec ls -ald {} \;
drwxrwxrwx 3 root root 4096 Dez  9 13:47 /tmp/samba_test
drwxrwx-wx 2 root root 4096 Dez  9 12:17 /tmp/samba_test/write_only
find: ‘/tmp/samba_test/write_only’: Keine Berechtigung
-rw-rw-r-- 1 www-data www-data 0 Dez  9 13:47 /tmp/samba_test/file

move file to write_only

mv /tmp/samba_test/file /tmp/samba_test/write_only
 find /tmp/samba_test -exec ls -ald {} \;
drwxrwxrwx 3 root root 4096 Dez  9 13:49 /tmp/samba_test
drwxrwx-wx 2 root root 4096 Dez  9 13:49 /tmp/samba_test/write_only
find: ‘/tmp/samba_test/write_only’: Keine Berechtigung

check that file is there as root

find /tmp/samba_test -exec ls -ald {} \;
drwxrwxrwx 3 root root 4096 Dez  9 13:49 /tmp/samba_test
drwxrwx-wx 2 root root 4096 Dez  9 13:49 /tmp/samba_test/write_only
-rw-rw-r-- 1 www-data www-data 0 Dez  9 13:47 /tmp/samba_test/write_only/file

So thats how Linux (the Filesystem ext4?) handles it. Write permissions are enough to move a file to a directory that is only writable but not readable.

Now lets do the same from Samba (Version 4.7.6-Ubuntu, Ubuntu 18.04)!

This is the samba configuration:

grep -vE "^([[:blank:]]*[#;]|$)" /etc/samba/smb.conf
[global]
   workgroup = <Our_Active_Directory>
   netbios name = <Our_Server_Hostname>
   security = ADS
   realm = <Our_Kerberos_Realm>
   encrypt passwords = yes
        server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[samba_test]
        comment = Test
        path = /tmp/samba_test

Now access the share in your Windows Explorer, create file2 in your share and try to move it to write_only. You'll receive an error that you need permissions for this task (to make changes to file2), those should be granted by . Even chmod 777 /tmp/samba_test/file2 does not change that.

Copying file2 does work (e.g. hold down CRTL to copy in the Windows Explorer)! (You can verify that it's there on your Linux-Machine)

Same behaviour if I do this with Powershell (Move-Item/Copy-Item).

If you do chmod o+r /tmp/samba_test/write_only moving a file there works.

Maybe there is a flag to change Samba's behaviour?

I've tested it with protocol version SMB1, SMB2, SMB3_11 and Samba version 4.7.6/3.6.23

Also tested it in a different environment at home with my raspberry pi. SMB3_11, Samba 4.9.5. This is a standalone Samba-Server used as network target for my canon printer.

I want incoming ssh-sessions to automatically disconnect upon inactivity for a security-critical server.

I've set the following settings

TCPKeepAlive no
ClientAliveInterval  30
ClientAliveCountMax 0

I would expect sshd not to send KeepAlive-Packages due to TCPKeepAlive and ClientAliveCountMax - and my sessions to timeout after 30 seconds. On top of that I think TCPKeepAlive could be left at its default which should be yes.

I've checked existing sessions like that:

root@<server>:/etc/apache2# w
 06:53:51 up 2 days, 21:25,  2 users,  load average: 0,00, 0,00, 0,00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
_____-ad pts/0    ____________      Do11    6.00s  0.99s  0.00s sshd: _____-admin [priv]
_____-us pts/1    ____________     06:40   13:26   0.02s  0.02s -bash

The sessions won't timeout...

I restarted sshd of course.

root@<server>:/etc/apache2# sshd -T | grep -i "ClientAlive"
clientaliveinterval 30
clientalivecountmax 0

Could the client still be sending KeepAlive-Packages? I cannot control all versions of clients that connect..

References: https://www.golinuxcloud.com/disconnect-idle-ssh-session-tcpkeepaliv-linux/ https://secscan.acron.pl/centos7/5/2/13

EDIT: TCPKeepAlive yes doesn't change the behaviour, sessions still linger. I also started a new session after I restarted sshd to avoid having old settings in my ssh-session.

EDIT2: Added keyword "incoming" to the description above to make it clearer, that I want my ssh server (sshd) to drop connections after an idle timeout, because users might forget about their open (and unsed) ssh sessions.

EDIT3: Just for information - used sshd version:

root@<server>:/etc/apache2# dpkg -l openssh-server
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version            Architektur  Beschreibung
+++-==============-==================-============-=================================================================
ii  openssh-server 1:8.2p1-4ubuntu0.1 amd64        secure shell (SSH) server, for secure access from remote machines
root@<server>:/etc/apache2# sshd -V
unknown option -- V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020

Working as expected in

• Debian 10 (OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019)*
• Ubuntu 16.04 (OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016)

*For Debian 10 I wanted to compare sshd -T. Options that differ: casignaturealgorithms, gssapikexalgorithms, hostbasedacceptedkeytypes, hostkeyalgorithms, kexalgorithms, passwordauthentication, permitrootlogin, pubkeyacceptedkeytypes, pubkeyauthoptions, securitykeyprovider

I've only set passwordauthentication no

I've connected from the same host, the only difference is I used pubkey authentication for the server in question and password authentication for the Debian 10 server.

Sorry that it's getting long.. It kinda turns into a bug report..

On Debian 10:

• ClientAliveInterval 10, ClientAliveCountMax 3: ssh -v records the message debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1 every 10 seconds
• ClientAliveInterval 10, ClientAliveCountMax 0: session disconnects after 10 seconds.

On Ubuntu 20.04:

• ClientAliveInterval 10, ClientAliveCountMax 0: ssh -v records the message debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1 every 10 seconds

I run the following code snippet:

#!/bin/bash
for i in $(seq 1 30); do
{
        # output missing
        #ssh root@MYHOST "echo hi"

        # works
        #bash -l -c "echo hi"
        #echo hi
}&
done | wc -l

If I run ssh in parallel (30 times) and count the returning lines, I receive a random amount, always less than 30. If I run echo hi in parallel (or within its own shell), I receive all 30 lines.

What is going wrong here?

P.S.: I know that there are other tools for parallelization like parallel or pssh, but I try to understand the problem described here.

Currently our Ubuntu-Clients connect to cifs shares during system boot via /etc/fstab. This has the following disadvantages:

• Passwords are written in plain text as mount option
• The password should expire, but if it does, the /etc/fstab has to be changed on every client. So most passwords used for mounts simply don't expire at the moment
• The CIFS share is mounted under the connecting user and his permissions, so the user actually working with the share on Ubuntu is not displayed. A side effect is a blur of permissions, because the Ubuntu-users are not listed in the Windows file system permissions.

What I already successfully tested on our Ubuntu-Clients: Using kerberos authentication on user login - so there is a kerberos ticket available for the user.

Using that kerberos ticket to (sudo) mount the cifs share within a systemd userservice

• PRO: Works on graphical login as well as ssh
• PRO: Share is accessible like the local file system
• CON: If I mount on a global mountpoint like /servers/mymount, I have to take care, that I don't overlay mounts by multile users. And the connecting user then would be the one who's permissions would be used by any following user.

Using that kerberos ticket to dynamically mount the share from the file browsers nautilus and thunar

• PRO: If the connection to the share is established via file browser, no extra script or service is necessary
• PRO: The share is mounted into the user context, so definitely with the users permission. If the user has no permission, there is still the possibility to connect the share with another user.
• PRO: The mounts could be automated by /etc/profile using gvfs-mount
• PRO: No sudo-rights are neccessary, the user can gvfs-mount and -unmount as he wishes, very intuitive via file browser
• CON: There is no actual mountpoint, standard unix commands like ls, cp and so on don't work. I would have to use gvfs-* alternatives. At this point the above solution with mount.cifs appears to be better.

So what I would like is to access the cifs share like I access an nfs share.

• No passwords used during the mount
• The permissions of the accessing user should be used
• The filesystem should behave like the local file system (standard unix commands should work)

I could mount a CIFS share multiple times, separately for each user into his home directory, but

Is there a way to mount the CIFS share during boot by the user root, not specifying a connecting user and then using the permissions from an accessing user (for example via kerberos ticket)?

Thank you in advance, Bastian