6

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).

Improve this question
1
  • I also can recommend you to take a look at the 'acl' package. Advanced ACL's is a lot more convinient comparing with traditional Unix ACL, and I'm using it all the time now. Commented Jan 17, 2017 at 9:23

1 Answer 1

Reset to default
1

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 can access the files as expected.

Improve this answer
1
  • I'd also like to add that this is host is an Azure-hosted VM. We have a support contract with MSFT and yet they dodged this incident like the plague. Commented Jan 6, 2017 at 0:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.