Linux and SMB permissions not working as expected

permissionssftpsmb

I configured a CentOS server to be a SFTP server that receives customer files in a secure way. Then I need to be able to access these files via SMB.

The 'root' of my SFTP is in /var/inbound/
Then under /var/inbound/ I have one directory for each customer (e.g. /var/inbound/customer1/
Then in order to jail users, I have a sub-directory called uploads under each customer directory (e.g. /var/inbound/customer1/uploads/)

I managed to make the permissions work as expected and everything is fine and dandy to support customer access to the SFTP. One important aspect is that I 'jailed' users to their /var/inbound/ directories.

Here is now I created the /var/inbound directory:

sudo mkdir /var/inbound
sudo chown root.root /var/inbound #root must be owner of directory

And here is how I create the sub-directories for each customer:

sudo mkdir -p /var/inbound/[username]/uploads
sudo chown root /var/inbound/[username]
sudo chmod go-w /var/inbound/[username]
sudo chown [username]: /var/inbound/[username]/uploads
sudo chmod 770 /var/inbound/[username]/uploads

NOTE: Both the /var/inbound/[username]/ and
/var/inbound/[username]/uploads/ directories need a special set of
permissions. Perform the following commands, replacing [username] with
the user in question.

Now I'll spare you from the remaining SSH/SFTP configuration. But suffice to say that I can get users to be jailed to their own directories, and that I disabled their SSH/console access using SCPONLY.

Now where things get complicated…

I now need to give SMB access to a specific account (let's call it fileaccess) to the /var/inbound/ directory, which will be accessible from a Windows Server host. I do manage to see the /var/inbound directory as a share from Windows, including its sub-directories. However I cannot see some files, and I have no write access to the files I am meant to have access to either.

$ ls -l /var/inbound
total 0
drwxr-xr-x. 3 root root 20 Jan  5 11:53 testuser

$ ls -l /var/inbound/testuser
total 0
drwxrwxr-x. 2 testuser sftponly 53 Jan  5 12:26 uploads

Now here is the directory I want to access with the fileaccess account:

$ ls -la /var/inbound/testuser/uploads/ 
total 12 
drwxrwx---. 2 testuser    sftponly   53 Jan 5 15:12  . 
drwxr-xr-x. 3 root        root       20 Jan 5 11:53  .. 
-rw-r--r--. 1 fileaccess  sftponly   30 Jan 5 12:26  test2.txt 
-rw-r--r--. 1 testuser    sftponly   26 Jan 5 12:25  test3.txt 
-rw-rw-r--. 1 dmgmadmin   dmgmadmin  14 Jan 5 11:53  test.txt

When I connect via SMB with the fileaccess account, I can only see the test.txt, but I cannot open the file (access denied).

Here is my smb.conf. As you can see I've been trying a series of different options:

    [global]
    workgroup = <MYDOMAINNAMEGOESHERE>
    security = user

    passdb backend = tdbsam

    [inbound]
    comment = Incoming files (as %u)
    path = /var/inbound/
    valid users = fileaccess
    guest ok = No
    read only = No
    writeable = Yes
    browseable = Yes
    create mask = 0640
    directory mask = 0750

NOTE: While I do have a domain, this CentOS machine is not part of it. It does have an entry on my Windows AD DNS, and is configured to use the DNS server — but that is the end of it. I want this machine to be isolated. So attempts to connect to this server are made with local CentOS accounts.

I am particularly concerned that this might be a Linux file-system access issue, and that necessary changes might conflict with required SFTP permissions (e.g. SFTP requires the /var/inbound// directories to be owned by root).

I wonder if there is a way to enforce in the SMB.conf the access rights for the account in question, so that account has browse/read/right permissions. I tried all sorts of config options in smb.conf (I've been reading the manual for smb.conf here).

Best Answer

Seems like I was chasing a zebra all along.

Thanks to the help of users derobert, terdon and others in the /dev/chat channel, we found out that the issue is indeed SELinux. In fact, the CentOS wiki documentation on Samba says the following:

"Now we're going to use the semanage command (part of the SELinux package) to open up the directory(s) you desire to share with the network. That's right. Without doing this, you'll start up samba and get a bunch of blank directories and panic thinking the server deleted all your data!"

So the command that I needed to perform was:

sudo semanage fcontext -a -t samba_share_t '/var/inbound(/.*)?'
sudo restorecon -R /var/inbound

And boom! Now I could access the files as expected.

Related Solutions

Linux – Make all files under a directory read-only without changing permissions

This answer works on Debian (tested on lenny and squeeze). After investigation, it seems to work only thanks to a Debian patch; users of other distributions such as Ubuntu may be out of luck.

You can use mount --bind. Mount the “real” filesystem under a directory that's not publicly accessible. Make a read-only bind mount that's more widely accessible. Make a read-write bind mount for the part you want to expose with read-write access.

mkdir /media/hidden /media/hidden/sdz99
chmod 700 /media/hidden
mount /dev/sdz99 /media/hidden/sdz99
mount -o bind,ro /media/hidden/sdz99/world-readable /media/world-readable
mount -o bind /media/hidden/sdz99/world-writable /media/world-writable

In your use case, I think you can do:

mkdir /var/smb/hidden
mv /var/smb/snapshot /var/smb/hidden
mkdir /var/smb/snapshot
chmod 700 /var/smb/hidden
chmod 755 /var/smb/hidden/snapshot
mount -o bind,ro /var/smb/hidden/snapshot /var/smb/hidden/snapshot

I.e. put the real snapshot directory under a restricted directory, but give snapshot read permissions for everyone. It won't be directly accessible because its parent has restricted access. Bind-mount it read-only in an accessible location, so that everyone can read it through that path.

(Read-only bind mounts only became possible several years after bind mounts were introduced, so you might remember a time when they didn't work. I don't know offhand since when they work, but they already worked in Debian lenny (i.e. now oldstable).)

SSH with chroot and only working “sftp”, “rsync” (both)

First of all ChrootDirectory must be owned by root and not writable by other users. Thus /var/shared in your case cannot be ChrootDirectory value.

I would recommend to create a directory which would be writable by root only and make /var/shared accessible inside this dir either via Linux bind-mounting or some kind of symlinks workarounds.

If you need restrict sftp or rsync, you need to check SSH_ORIGINAL_COMMAND environment variable on the server with help of a "wrapper" enforced either via ForceCommand or via command in ssh public key, this variable is populated after user is authenticated and contains info what kind of connection clients is going to establish. For sftp it would have sftp-server inside, for rsync it would have rsync, for just ssh session it would have, IIRC, the variable empty, for ssh date it would be date. SSH_ORIGINAL_COMMAND is run under authenticated user on the server!

This could be your start of the wrapper:

#!/usr/bin/env bash

set -eu
set -o pipefail

[[ -z "${SSH_ORIGINAL_COMMAND:-}" ]] && exit 1

case "${SSH_ORIGINAL_COMMAND}" in
    "/usr/libexec/openssh/sftp-server")
        exec /usr/libexec/openssh/sftp-server
        ;;
    "rsync --server"*)
        exec ${SSH_ORIGINAL_COMMAND}
        ;;
    *)
        exit 1
        ;;
esac

As you can see, ssh -v gives you info about what command would be executed by the server. Thus you can change /tmp to something else in your wrapper as well.

$ rsync -a -e "ssh -v" bin localhost:/tmp/ 2>&1 | grep '^debug.*Sending command:'
debug1: Sending command: rsync --server -logDtpre.iLsfxC . /tmp/

Best Answer

Related Solutions

Linux – Make all files under a directory read-only without changing permissions

SSH with chroot and only working “sftp”, “rsync” (both)

Related Question