Samba Rights When Working With NCP Volumes

Samba can access two types of filesystems.  The first are POSIX-based (ie. rwxr-wr-w, or 755) filesystems, such as reiserfs and ext3.  The other type is NSS.  With either type, there is a single point of rights management.  With POSIX-based, ACLs can be used (on the filesystem itself or within Samba).  With NSS, the rights are handled through eDirectory.  This document, however, is to explain how to work with Samba rights when dealing with NCP volumes.

 

In OES and NOWS-SBE the administrator can create and use NCP volumes. NSS volumes, while a special type of NCP volume, is not supported or available under NOWS 2.0, but is available under NOWS 2.5..  NCP volumes, or volumes that can be accessed via the NCP protocol, are supported (non-NSS) in both NOWS 2.0 and 2.5.  For NOWS 2.0 there is no single point of rights management should an administrator choose to share the NCP volume via Samba. 

 

The administrator will need to configure both filesystem trustees/rights  to manage NCP connections and POSIX rights on the filesystem for Samba if access to the share will be available over both protocols.

 

1.  iManager:

2.  Command Line:

 POSIX rights considerations

 

 Volumes can be written about POSIX rights. There are volumes out on the web.  The same can be said about ACLs that can be set within Samba, and how filesystem ACLs and Samba ACLs interact and take priority over one another.  The intent of this document is not to cover any of that (again, as it can take up volumes).  This document is to make the administrator aware of something things to consider, and in some cases some "gotchas" that can cause administrative headaches. 

 

Unlike NetWare, the administrator cannot restrict access at the root of the share (to a degree) and add the rights further down in a subdirectory.  For instance, consider the following NCP volume path:

/home/level1/level2/file.txt

 

The ncpserv.conf shows that the ncpvolume HOME maps to /home.  The permissions on /home are:

 

nows:/ # getfacl --all-effective home/
# file: home
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

 

Note that the owner and group are both root.  As the root user, rwx permissions are assigned.  The group only has read and execute, as does other.  This is perfectly normal, and is what the permissions need to be at the root of the ncpvolume (and on every subdirectory).  This means that the subdirectory level1 would look the same, level2, and so on.  The file, by default, will have 644 (or rw-r--r--).  If the administrator then wishes to restrict the test user "user1" from being able to access the file.txt file (via ACLs), the administrator can do the following:

 

nows: cd /home/level1/level2

nows:/home/level1/level2 # setfacl -m u:user1:--- file.txt
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
user::rw-
user:user1:---                   #effective:---
group::r--                         #effective:r--
mask::r--
other::r--

 

NOTE: Setting ACLs, removing them, and so on will not be covered here.  The man pages for setfacl and getfacl will get the administrator started. 

 

In the above example, rights were explicitly stripped from user1 on the file.  This could have been done at the directory level with the same effect. 

 

In the following example, the permissions will be incorrectly set.  Consider the following:

 

nows:chmod -R 700 /home

nows:/ # cd /home/level1/level2/
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
user::rwx
group::---
other::---

 

Note that only the root user has permissions to do anything to this file (the same is true to the directory). 

As an administrator, I may be thinking that I am only allowing root user to have access to this directory and its contents.  This is true, however, I cannot do the following on any subdirectories or files and expect it to work:

 

nows:/home/level1/level2 # setfacl -m u:user1:rwx file.txt
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
user::rwx
user:user1:rwx                  #effective:rwx
group::---                      #effective:---
mask::rwx
other::---

Notice that user1 has full rwx permissions on the file.  This is deceptive though, because user1 (as he is not the root user) does not have any permissions on the directory.  This user will not be able to see or manipulate the file through a Samba connection.  In order to have full rights to this file, the user will need at least r-x permissions on all directories up to the root of the path.  This means that in the path /home/level1/level2/file.txt, /home, level1, and level2 will need to have at least r-x permissions for either the user, or a group the user belongs to (or both--which is default). 

 

As a quick summary review, in order for a user to do anything in a directory or file, the user should have r-x permissions on all directories from the current working directory up through all parent directories to the root.  If the user doesn't, despite what ACLs may be set on a particular file or subdirectory, that user will not be able to do what their rights may specify.

 

#############################

 

With two different protocols being used to access a share (smb/cifs and ncp), some problems can occur.  For instance, consider the following file

nows:/home/level1/level2 # getfacl --all-effective new_test.txt
# file: new_test.txt
# owner: JohnDoe

# group: MyGroup
user::rwx
group::rwx                     

mask::rwx

 

The new_test.txt file above has POSIX permissions of 777 (or rwx for user, group, and other).  If a user connects through a Novell NCP client, modifies and saves the file, the owning user will be changed to the user that changed and saved the file.  The owning group will be changed to 'root' and the default permissions will likely change to rw------- (read, write for the user only).  This presents a problem when trying to share a file with many users.  NCP provides a switch called "Inherit_POSIX_Permissions" to get around this.  When set, files will inherit the GID and mode bits of the parent directory.  This means that if the new_test.txt file resides in the "level2" directory, and the directory has permissions of 777 and is owned by SomeUser and SomeGroup, then the modified new_test.txt file (as modified through the NCP client) will have the owner of CurrentUser, the group SomeGroup, and will have rw-rw-rw- (or 666) on the file.  If the user creates subdirectories it will be the same (except the permissions will be 777 or rwxrwxrwx).  For more information about the "Inherit_POSIX_Permissions" switch, please see section 10.8 of the Storage Administration Guide under the OES 2 documentation.