jkeegan123
asked on
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 //192.168.1.3/data -o username=user,password=pas sword)
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.
Thanks!
- 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 //192.168.1.3/data -o username=user,password=pas
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.
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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 //192.168.1.5/share -o umask=666,dmask=777,userna me=admin,p assword=pa ssword /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 //192.168.1.6/shared -o krb,umask=666,dmask=777,us ername=adm in,passwor d=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.
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 //192.168.1.5/share -o umask=666,dmask=777,userna
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 //192.168.1.6/shared -o krb,umask=666,dmask=777,us
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.
# 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