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

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

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.

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.