[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 415
  • Last Modified:

Security issues on a remotely mounted filesystem

I am trying to mount a Network Attached Storage device onto a RedHat Enterprise Linux system (RHEL3), and am having some security issues.  Here's what I've done:

- I create a folder in /mnt/terra
- I assign full security rights for everyone to this folder (chmod 777 /mnt/terra)
- I mount the file system (mount -t smbfs // -o username=user,password=password)

After I do this, the folder /mnt/terra changes back to permissions:  rwrr_xr_w, which doesn't let attached non-root users write to it.

I've also tried after the above commands:

- creating a folder /home/terra
- setting permissions on /home/terra (chmod 777 /home/terra)
- Creating a symbolic link to /mnt/terra (ln -s /home/terra /mnt/terra)

And my users get the same LACK of permissions.

Can anyone shed some light on this, I really need to get this storage space online.

  • 2
1 Solution
you can find in your smb.conf the directory mask replace it for 777
  directory mask = 0777

this is a part of smb.conf that you need to modify

# File creation mask is set to 0600 for security reasons. If you want to
# create files with group=rw permissions, set next parameter to 0664.
   create mask = 0600

# Directory creation mask is set to 0700 for security reasons. If you want to
# create dirs. with group=rw permissions, set next parameter to 0775.
   directory mask = 0700

jkeegan123Author Commented:
I found the answer, all I had to do was add some options to the MOUNT command to accomplish what I needed.

What was happening:  before mounting a remote filesystem onto a folder, the folder's permissions were "777".  After mounting a remote filesystem onto this folder, the folder became "755", or only writable by owner, listable and accessable by everyone else (effectively read only for all but ROOT).  This only happened AFTER the filesystem was mounted onto that folder.  Now, I had the misconception that the permissions BEFORE mounting had something to do with perissions AFTER mounting:  THEY DON'T.  This took a while to realize, as a windows guy that is unfamiliar with Linux.

Apparantly, when a remote filesystem is mounted, it takes the UMASK of the existing files in that filesystem (the parent folder where your MOUNT folder lives, or in this case, "/mnt").  I may be wrong about this exactly fact, and if I am please someone correct me, but the mounted filesystem DEFINITELY inherits permissions from somewhere, and again, it has NOTHING to do with the permissions of the folder that the remote filesystem will be mounted to BEFORE the mounting.

The change:  specify "fmask" and "dmask" options in the mount command.  What I ended up using was:

mount -t smbfs // -o umask=666,dmask=777,username=admin,password=password /mnt/terra

After I did this, the permissions of the mounted folder showed "777" or, "rwxrwxrwx".  WOO-HOO!

Also, during this journey, I crashed a SUSE box twice trying to mount a share on a Windows 2003 domain controller.  The reason for this each time was the absence of the KERBEROS (krb) switch in the mount command line.   The following was the command that allowed me to mount a share on a Windows Domain controller:

mount -t smbfs // -o krb,umask=666,dmask=777,username=admin,password=password /mnt/terra

FINALLY, if you're reading this and discovering how to mount filesystems like I was, take this advice:  it's MUCH easier to type "umount /mnt/terra" than to type the whole command.  

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now