Samba Permissions Issue - permissions

I have samba services (v 4.3.9) set up on a development web server. For simplicity sake, I have a folder "/samba/billfolder" that requires access from the web service AND my samba users. When a samba user creates a file or folder, the permissions are not properly set and the web service cannot access the file / folder. I need a folder that I can create folders and files that will give full permissions to both groups
My smb.conf look like this:
[global]
workgroup = MYDOMAIN.LOCAL
server string = Samba Server %v
netbios name = TestServer
security = user
#============================ Share Definitions ==============================
[Billing]
path=/samba/billfolder
valid users = #alfdevelopers, #www-data
guest ok = no
writeable = yes
browsable = yes
create mask = 0664
force directory mode = 2775
Can someone please offer some suggestions on how to properly do this. The client machine is LinuxMint and the fstab entry looks like this:
//192.168.1.200/Billing /mnt/Billing cifs user=myuser,password=mypassword,rw,iocharset=utf8 0 0
Thanks for any help that can be provided.

Your samba configuration seems correct. File permissions, group permission from the linux filesystem are checked and applied after the inital samba configuration stage.
Create a common group having users from #alpha-developers & www-data say for example #developerswebservices. You can easily add the necessary users to the group using /etc/group file.
developerswebservices:x:xx: user1,user2,www-data
Put users from both the groups as shown above.Go to the working directory of the share i.e Billing
Force the newly created file inside to belong to the group of the parent, i.e Billing,
$sudo chgrp -R developerswebservices Billing
$sudo chmod -R g+s Billing
You can change the permission create mask with the necessary mask bits using the umask command.
test#linuxserver:/$umask 0007
This wil give permission to newly created file to the user test as rw-rw--- for the user test.
Umask allows you to set the default permission bits for a file/directory
creation for a user.
To customize the umask for all users specify the umask bits in the /etc/login.defs file.
Hope this helps ! Thanks.

Related

rsync daemon and permissions

Problem
I am confused about rsync daemon and permissions. Unfortunately I cannot figure out why I get
rsync: opendir "/." (in share) failed: Permission denied (13) and
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2].
Obviously, by searching the web and looking into the manpage of rsync / rsyncd.conf I was not able to solve this issue.
Setup
Here is my /etc/rsyncd.conf owned by root with 644 permissions:
log file = /var/log/rsyncd.log
[share]
comment = data
path = /path/to/data
uid = root
gid = root
read only = false
auth users = syncuser
secrets file = /etc/rsyncd.secrets
Note, /path/to/data is owned by root with 755 permissions (though random user or syncuser is also not working).
Besides, /etc/rsyncd.secrets has 600 permissions and is owned by root (I also tried 400 though same issue)
syncuser:passwd
To start the service (on CentOS7)
sudo systemctl start rsyncd
A first test as a random user on the host machine running the daemon, (also running with sudo or as syncuser has no effect)
rsync user#host::
returns share data showing that the configuration is fine?!
However
rsync user#host::share
leads to the errors mentioned above.
Tries
Playing with chmod (777) and chown (root:root, random user:user, syncuser:syncuser) of /path/to/data was not changing anything. Moreover I varied uid and gid to nobody but also without success.
Running above rsync command on an actual client, from which I want to ultimately copy data to the host is of course also failing.
So what am I missing here? Any hints are of course highly appreciated.
could you check SELinux?
If it is enforced, the directory /path/to/data need to be labeled correctly.
For example,
chcon -R -t public_content_t /path/to/data

Always permission 777 on mount shared cifs

I have a little problem when I mount a SMB shared folder from a Synology NAS.
I want to mount a shared folder with permissions: git:root 700
But the mounted folder always have permission set to 777 ( even after a chmod 700 without error)
In my /etc/fstab I used this line:
#uid=999 ---> git user
//server/folder /mnt/artifacts cifs username=windowsUser,password=xxxxx,gid=0,uid=999,file_mode=0700,dir_mode=0700,iocharset=utf8 0 0
Do you know why I cannot set my rights to 700 ?
I did a mistake ? Something stupid ?
Thanks in advance for your help ;)
If the remote machine user ID and the local machine user ID do not match, the permissions will default to 777. Mount.cifs doesn't support umask, so instead "noperm" option can be used. This way even if the permissions of the users on the local and remote machines don't match, the user will still be allowed to read and write to the folder, the equivalent of umask=000.
//address/location /mount/location cifs username=username,password=password,noperm,vers=2.0 0 0
a good start is to check out the manpage for CIFS:
$ man mount.cifs
[...]
file_mode=arg
If the server does not support the CIFS Unix extensions this overrides the default file mode.
dir_mode=arg
If the server does not support the CIFS Unix extensions this overrides the default mode for directories.
[...]
nounix
Disable the CIFS Unix Extensions for this mount.
[...]
So since the file_mode (and dir_mode) seem to only work if the server does not support the CIFS Unix extensions, i would start by disabling them (via the nounix option)
Adding nounix worked just fine. For information, the line I have in /etc/fstab is :
//server/share /mnt/folder cifs credentials=/home/yannick/.smbcredentials,iocharset=utf8,sec=ntlm,vers=1.0,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,nounix 0 0
with 1000 being my user id and group id.
Inside .smbcredentials, I have this :
username=<distant login>
password=<distant password>
I try to mount a CIFS share with permissions only for root. Other users should not be able to even list any files.
Therefore I used the following fstab entry:
//192.168.0.100/DRV /mnt/DRV cifs user=user,pass=pass,uid=0,gid=0,nounix,file_mode=0007,dir_mode=0007 0 0
I also tried the noperm parameter.
In detail I created the folder with this permissions:
drwxrwx--- 2 root root 4096 Mai 14 09:09 DRV
After mounting the network share, the folder have:
d------rwx 2 root root 4096 Mai 14 04:50 W
Your problem is a very common one. You are using incorrect tags to be able to change the file permissions of the mounted folder.
You need to add 'umask=', instead of 'file_mode=700' and 'dir_mode=700' as it is using system mount options not CIFS's options.
To do this you can use:
//address/location /mount/location cifs credentials=/location,uid=id,gid=id,umask=700 0 0
This will mount the file share under the set file permissions.
For security I would recommend using a credentials file, which contains the username and password, and must be set as read only.

PAM UMASK not respected on NFS

I have make directory enabled in /etc/pam.d/common-session with the session optional pam_mkhomedir.so umask=000
I using Samba Winbind to authenticate domain users. So, in smb.conf, i have
template homedir = /nfs/upload/%U
Note: its intentional that home dir is set to 777 permissions, it will be on a NFS mount and need full access for everyone
The problem is
If /nfs is a local directory, the home directory permissions are 777 as expected
If /nfs is an NFS mount, then the directory is created with 700 -- Not sure how to fix this
thank you all

Creating per-user php5-fpm pools the secure way

When creating per-user php5-fpm pools on an Apache mod_fastcgi setup which of the following is the most secure way and efficient way of granting webserver permissions to the PHP pool?
Option 1:
Set the group to www-data:
listen.owner = username
listen.group = www-data
listen.mode = 0660
user = username
group = www-data
While this works files created by PHP would have the ownership set to username:www-data while files uploaded via SCP will have username:username.
Option 2:
Add www-data to the supplementary group username:
listen.owner = username
listen.group = username
listen.mode = 0660
user = username
group = username
-
usermod -aG username www-data
Which of these options are secure? You may also share a better method.
I checked the following guides:
http://www.howtoforge.com/php-fpm-nginx-security-in-shared-hosting-environments-debian-ubuntu
http://www.binarytides.com/php-fpm-separate-user-uid-linux/
But they were all written before bug #67060 was discovered and fixed.
I am using following setup on my LEMP (Nginx + PHP-FPM). For Apache this should also be applicable.
PHP-FPM runs several pools as nobody:user1, nobody:user2 ...
Nginx runs as nginx:nginx
User nginx is a member of each user1, user2.. groups:
# usermod -a -G user5 nginx
File permissions:
root:root drwx--x--x /home
user1:user1 drwx--x--- /home/user1 (1)
user1:user1 rwxr-x--- /home/user1/site.com/config.php (2)
user1:user1 drwxrwx--- /home/user1/site.com/uploads (3)
nobody:user1 rw-rw---- /home/user1/site.com/uploads/avatar.gif (4)
(1) User's home dir has no x permission for other, so php-fpm pool running as nobody:user2 will not have access to /home/user1 and vice versa.
(2) php script doesn't have w for group, so it cannot create files in htdocs.
(3) On uploads dir we should manually enable write access for group user1, to enable php script to put files there. Don't forget to disable php handler for uploads, in nginx this is made by
server {
....
location ^~ /uploads/ { }
but for Apache you should check.
(4) uploaded files should also have w for group if we want user1 to be able to edit these files later via ftp or ssh (logging in as user1:user1). Php code is also editable via ftp since user1 is its owner.
Nginx will have read access to all users and write access to all user's uploads since user nginx is a member of each user1, user2, ... groups.
You should not forget to add it to all later groups. You can also modify useradd script to do it automatically.

Samba (Cannot Write) issue

I have setup Samba between two linux boxes (Ubuntu Desktop 12.10 and Ubuntu Server 12.04). For some reason I cannot write to my samba share. To me it looks like I have the correct permissions. Below is my smb.conf, the filesystem permissions, and the steps I followed. I definitely have it misconfigured but I cannot find out how. Any help would be appreciated. Craig
Created a user in ubuntu server (craig)
Created a user and password in samba "smbuseradd -a craig" set the password
Mounted the samba share from linux desktop. This seemed to mount just fine
Attempted to write a file and it says that I don't have write permissions
Permissions on the server when viewed from the server "drwxrwxrwx 4 Craig Craig"
Permissions when viewed from ubuntu desktop "drwxr-xr-x 0 root root"
[global]
follow symlinks = yes
wide links = yes
unix extensions = no
workgroup = Ubuntu Precise
security = user
unix password sync = yes
[homes]
comment = Home Directories
browseable = yes
writable=yes
create mask = 0777
directory mask = 0777
guest ok = yes
[share]
comment = Precise File Server
path = /home/craig
browsable = yes
guest ok = yes
read only = no
writable = yes
create mask = 0777
directory mask = 0777
EDIT:
If I open my samba share as root then I can write to the folders. I tried doing a chmod and chgrp but that didn't seem to have any impact. I would prefer not to have to browse/write as root :)
Ok, figured it out. It wasn't in my samba settings. The error was actually in how I was "permanently" mounting my samba share.
I was doing:
//192.168.1.11/craig /home/craig/musicServer cifs username=craig,password=MYPASSWORD 0 0
but I needed
//192.168.1.11/craig /home/craig/musicServer cifs username=craig,password=MYPASSWORD,file_mode=0777,dir_mode=0777 0 0
Adding both file_mode and dir_mode solved it.
The difference in owner printout is probably due to different UID/GID you have on your local and remote machines.
You can use noperm option at mount instead (no need for file_mode or dir_mode). This option turns off the local file permission check (so UID/GID inconsistency will be okay) and assume the remote identity you authenticated at mount. Remote access control is still enforced.