From d85ffb3e70189648cd2d0c8113dc3d8085ff80bc Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sun, 11 May 2003 07:45:07 +0000 Subject: Extending Samba Access Control Info --- docs/docbook/global.ent | 2 +- docs/docbook/projdoc/AccessControls.xml | 547 ++++++++++++++++++++++++++ docs/docbook/projdoc/AdvancedNetworkAdmin.xml | 108 ----- docs/docbook/projdoc/NT_Security.xml | 335 ---------------- docs/docbook/projdoc/samba-doc.xml | 15 +- 5 files changed, 556 insertions(+), 451 deletions(-) create mode 100644 docs/docbook/projdoc/AccessControls.xml delete mode 100644 docs/docbook/projdoc/NT_Security.xml diff --git a/docs/docbook/global.ent b/docs/docbook/global.ent index 6a70b30940a..6a494fcf2b3 100644 --- a/docs/docbook/global.ent +++ b/docs/docbook/global.ent @@ -450,6 +450,7 @@ an Active Directory environment. + @@ -463,7 +464,6 @@ an Active Directory environment. - diff --git a/docs/docbook/projdoc/AccessControls.xml b/docs/docbook/projdoc/AccessControls.xml new file mode 100644 index 00000000000..c903af4468e --- /dev/null +++ b/docs/docbook/projdoc/AccessControls.xml @@ -0,0 +1,547 @@ + + + &author.jht; + &author.jeremy; + May 10, 2003 + +File, Directory and Share Access Controls + + +Advanced MS Windows users are frequently perplexed when file, directory and share manipulation of +resources shared via Samba do not behave in the manner they might expect. MS Windows network +adminstrators are often confused regarding network access controls and what is the best way to +provide users with the type of access they need while protecting resources from the consequences +of untoward access capabilities. + + + +Unix administrators frequently are not familiar with the MS Windows environment and in particular +have difficulty in visualizing what the MS Windows user wishes to achieve in attempts to set file +and directory access permissions. + + + +The problem lies in the differences in how file and directory permissions and controls work +between the two environments. This difference is one that Samba can not completely hide, even +though it does try to make the chasm transparent. + + + +POSIX Access Control List technology has been available (along with Extended Attributes) +for Unix for many years, yet there is little evidence today of any significant use. This +explains to some extent the slow adoption of ACLs into commercial Linux products. MS Windows +administrators are astounded at this given that ACLs were a foundational capability of the now +decade old MS Windows NT operating system. + + + +The purpose of this chapter is to present each of the points of control that are possible with +Samba-3 in the hope that this will help the network administrator to find the optimum method +for delivering the best environment for MS Windows desktop users. + + + +This is an opportune point to mention that it should be borne in mind that Samba was created to +provide a means of interoperability and interchange of data between two operating environments +that are quite different. It was never the intent to make Unix/Linux like MS Windows NT. Instead +the purpose was an is to provide a sufficient level of exchange of data between the two environments. +What is available today extends well beyond early plans and expections, yet the gap continues to +shrink. + + + +Features and Benefits + + + Samba offers a lot of flexibility in file system access management. These are the key access control + facilities present in Samba today: + + + + Samba Access Control Facilities + + Unix file and directory permissions + + + + Samba Share Definitions + + + + Samba Share ACLs + + + + MS Windows ACLs through Unix POSIX ACLs + + + + + + +File System Access Controls + + +Explain here how Unix file and permissions work + + + + + +Share Definition Access Controls + + +Explain here about the smb.conf [share] parameters + + + + + +Access Controls on Shares + + + This section deals with how to configure Samba per share access control restrictions. + By default samba sets no restrictions on the share itself. Restrictions on the share itself + can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can + connect to a share. In the absence of specific restrictions the default setting is to allow + the global user Everyone Full Control (ie: Full control, Change and Read). + + + + At this time Samba does NOT provide a tool for configuring access control setting on the Share + itself. Samba does have the capacity to store and act on access control settings, but the only + way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for + Computer Management. + + + + Samba stores the per share access control settings in a file called share_info.tdb. + The location of this file on your system will depend on how samba was compiled. The default location + for samba's tdb files is under /usr/local/samba/var. If the tdbdump + utility has been compiled and installed on your system then you can examine the contents of this file + by: tdbdump share_info.tdb. + + + + Share Permissions Management + + + The best tool for the task is platform dependant. Choose the best tool for your environmemt. + + + + Windows NT4 Workstation/Server + + The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. + Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. + You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below. + + + + Instructions + + Launch the NT4 Server Manager, click on the Samba server you want to administer, then from the menu + select Computer, then click on the Shared Directories entry. + + + + Now click on the share that you wish to manage, then click on the Properties tab, next click on + the Permissions tab. Now you can Add or change access control settings as you wish. + + + + + + + Windows 200x/XP + + + On MS Windows NT4/200x/XP system access control lists on the share itself are set using native + tools, usually from filemanager. For example, in Windows 200x: right click on the shared folder, + then select 'Sharing', then click on 'Permissions'. The default Windows NT4/200x permission allows + Everyone Full Control on the Share. + + + + MS Windows 200x and later all comes with a tool called the 'Computer Management' snap-in for the + Microsoft Management Console (MMC). This tool is located by clicking on Control Panel -> + Administrative Tools -> Computer Management. + + + + Instructions + + After launching the MMC with the Computer Management snap-in, click on the menu item 'Action', + select 'Connect to another computer'. If you are not logged onto a domain you will be prompted + to enter a domain login user identifier and a password. This will authenticate you to the domain. + If you where already logged in with administrative privilidge this step is not offered. + + + + If the Samba server is not shown in the Select Computer box, then type in the name of the target + Samba server in the field 'Name:'. Now click on the [+] next to 'System Tools', then on the [+] + next to 'Shared Folders' in the left panel. + + + + Now in the right panel, double-click on the share you wish to set access control permissions on. + Then click on the tab 'Share Permissions'. It is now possible to add access control entities + to the shared folder. Do NOT forget to set what type of access (full control, change, read) you + wish to assign for each entry. + + + + + + Be careful. If you take away all permissions from the Everyone user without removing this user + then effectively no user will be able to access the share. This is a result of what is known as + ACL precidence. ie: Everyone with NO ACCESS means that MaryK who is part of the group Everyone + will have no access even if this user is given explicit full control access. + + + + + + + + + +MS Windows Access Control Lists and Unix Interoperability + + + Viewing and changing UNIX permissions using the NT + security dialogs + + Windows NT clients can use their native security settings + dialog box to view and modify the underlying UNIX permissions. + + Note that this ability is careful not to compromise + the security of the UNIX host Samba is running on, and + still obeys all the file permission rules that a Samba + administrator can set. + + + + All access to Unix/Linux system file via Samba is controlled at + the operating system file access control level. When trying to + figure out file access problems it is vitally important to identify + the identity of the Windows user as it is presented by Samba at + the point of file access. This can best be determined from the + Samba log files. + + + + + + How to view file security on a Samba share + + From an NT4/2000/XP client, single-click with the right + mouse button on any file or directory in a Samba mounted + drive letter or UNC path. When the menu pops-up, click + on the Properties entry at the bottom of + the menu. This brings up the file properties dialog + box. Click on the tab Security and you + will see three buttons, Permissions, + Auditing, and Ownership. + The Auditing button will cause either + an error message A requested privilege is not held + by the client to appear if the user is not the + NT Administrator, or a dialog which is intended to allow an + Administrator to add auditing requirements to a file if the + user is logged on as the NT Administrator. This dialog is + non-functional with a Samba share at this time, as the only + useful button, the Add button will not currently + allow a list of users to be seen. + + + + + Viewing file ownership + + Clicking on the "Ownership" button + brings up a dialog box telling you who owns the given file. The + owner name will be of the form : + + "SERVER\user (Long name)" + + Where SERVER is the NetBIOS name of + the Samba server, user is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). Click on the Close + button to remove this dialog. + + If the parameter nt acl support + is set to false then the file owner will + be shown as the NT user "Everyone". + + The Take Ownership button will not allow + you to change the ownership of this file to yourself (clicking on + it will display a dialog box complaining that the user you are + currently logged onto the NT client cannot be found). The reason + for this is that changing the ownership of a file is a privileged + operation in UNIX, available only to the root + user. As clicking on this button causes NT to attempt to change + the ownership of a file to the current user logged into the NT + client this will not work with Samba at this time. + + There is an NT chown command that will work with Samba + and allow a user with Administrator privilege connected + to a Samba server as root to change the ownership of + files on both a local NTFS filesystem or remote mounted NTFS + or Samba drive. This is available as part of the Seclib + NT security library written by Jeremy Allison of + the Samba Team, available from the main Samba ftp site. + + + + + Viewing file or directory permissions + + The third button is the "Permissions" + button. Clicking on this brings up a dialog box that shows both + the permissions and the UNIX owner of the file or directory. + The owner is displayed in the form : + + "SERVER\user (Long name)" + + Where SERVER is the NetBIOS name of + the Samba server, user is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). + + If the parameter nt acl support + is set to false then the file owner will + be shown as the NT user "Everyone" and the + permissions will be shown as NT "Full Control". + + + The permissions field is displayed differently for files + and directories, so I'll describe the way file permissions + are displayed first. + + + File Permissions + + The standard UNIX user/group/world triple and + the corresponding "read", "write", "execute" permissions + triples are mapped by Samba into a three element NT ACL + with the 'r', 'w', and 'x' bits mapped into the corresponding + NT permissions. The UNIX world permissions are mapped into + the global NT group Everyone, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + user icon and an NT local + group icon respectively followed by the list + of permissions allowed for the UNIX user and group. + + As many UNIX permission sets don't map into common + NT names such as "read", + "change" or "full control" then + usually the permissions will be prefixed by the words + "Special Access" in the NT display list. + + But what happens if the file has no permissions allowed + for a particular UNIX user group or world component ? In order + to allow "no permissions" to be seen and modified then Samba + overloads the NT "Take Ownership" ACL attribute + (which has no meaning in UNIX) and reports a component with + no permissions as having the NT "O" bit set. + This was chosen of course to make it look like a zero, meaning + zero permissions. More details on the decision behind this will + be given below. + + + + Directory Permissions + + Directories on an NT NTFS file system have two + different sets of permissions. The first set of permissions + is the ACL set on the directory itself, this is usually displayed + in the first set of parentheses in the normal "RW" + NT style. This first set of permissions is created by Samba in + exactly the same way as normal file permissions are, described + above, and is displayed in the same way. + + The second set of directory permissions has no real meaning + in the UNIX permissions world and represents the + "inherited" permissions that any file created within + this directory would inherit. + + Samba synthesises these inherited permissions for NT by + returning as an NT ACL the UNIX permission mode that a new file + created by Samba on this share would receive. + + + + + Modifying file or directory permissions + + Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the OK button. However, there are + limitations that a user needs to be aware of, and also interactions + with the standard Samba permission masks and mapping of DOS + attributes that need to also be taken into account. + + If the parameter nt acl support + is set to false then any attempt to set + security permissions will fail with an "Access Denied" + message. + + The first thing to note is that the "Add" + button will not return a list of users in Samba (it will give + an error message of "The remote procedure call failed + and did not execute"). This means that you can only + manipulate the current user/group/world permissions listed in + the dialog box. This actually works quite well as these are the + only permissions that UNIX actually has. + + If a permission triple (either user, group, or world) + is removed from the list of permissions in the NT dialog box, + then when the "OK" button is pressed it will + be applied as "no permissions" on the UNIX side. If you then + view the permissions again the "no permissions" entry will appear + as the NT "O" flag, as described above. This + allows you to add permissions back to a file or directory once + you have removed them from a triple component. + + As UNIX supports only the "r", "w" and "x" bits of + an NT ACL then if other NT security attributes such as "Delete + access" are selected then they will be ignored when applied on + the Samba server. + + When setting permissions on a directory the second + set of permissions (in the second set of parentheses) is + by default applied to all files within that directory. If this + is not what you want you must uncheck the "Replace + permissions on existing files" checkbox in the NT + dialog before clicking "OK". + + If you wish to remove all permissions from a + user/group/world component then you may either highlight the + component and click the "Remove" button, + or set the component to only have the special "Take + Ownership" permission (displayed as "O" + ) highlighted. + + + + Interaction with the standard Samba create mask + parameters + + There are four parameters + to control interaction with the standard Samba create mask parameters. + These are : + + security mask + force security mode + directory security mask + force directory security mode + + Once a user clicks "OK" to apply the + permissions Samba maps the given permissions into a user/group/world + r/w/x triple set, and then will check the changed permissions for a + file against the bits set in the + security mask parameter. Any bits that + were changed that are not set to '1' in this parameter are left alone + in the file permissions. + + Essentially, zero bits in the security mask + mask may be treated as a set of bits the user is not + allowed to change, and one bits are those the user is allowed to change. + + + If not set explicitly this parameter is set to the same value as + the create mask + parameter. To allow a user to modify all the + user/group/world permissions on a file, set this parameter + to 0777. + + Next Samba checks the changed permissions for a file against + the bits set in the + force security mode parameter. Any bits + that were changed that correspond to bits set to '1' in this parameter + are forced to be set. + + Essentially, bits set in the force security mode + parameter may be treated as a set of bits that, when + modifying security on a file, the user has always set to be 'on'. + + If not set explicitly this parameter is set to the same value + as the force + create mode parameter. + To allow a user to modify all the user/group/world permissions on a file + with no restrictions set this parameter to 000. + + The security mask and force + security mode parameters are applied to the change + request in that order. + + For a directory Samba will perform the same operations as + described above for a file except using the parameter + directory security mask instead of security + mask, and force directory security mode + parameter instead of force security mode + . + + The directory security mask parameter + by default is set to the same value as the directory mask + parameter and the force directory security + mode parameter by default is set to the same value as + the force directory mode parameter. + + In this way Samba enforces the permission restrictions that + an administrator can set on a Samba share, whilst still allowing users + to modify the permission bits within that restriction. + + If you want to set up a share that allows users full control + in modifying the permission bits on their files and directories and + doesn't force any particular bits to be set 'on', then set the following + parameters in the &smb.conf; file in that share specific section : + + security mask = 0777 + force security mode = 0 + directory security mask = 0777 + force directory security mode = 0 + + + + Interaction with the standard Samba file attribute + mapping + + Samba maps some of the DOS attribute bits (such as "read + only") into the UNIX permissions of a file. This means there can + be a conflict between the permission bits set via the security + dialog and the permission bits set by the file attribute mapping. + + + One way this can show up is if a file has no UNIX read access + for the owner it will show up as "read only" in the standard + file attributes tabbed dialog. Unfortunately this dialog is + the same one that contains the security info in another tab. + + What this can mean is that if the owner changes the permissions + to allow themselves read access using the security dialog, clicks + "OK" to get back to the standard attributes tab + dialog, and then clicks "OK" on that dialog, then + NT will set the file permissions back to read-only (as that is what + the attributes still say in the dialog). This means that after setting + permissions and clicking "OK" to get back to the + attributes dialog you should always hit "Cancel" + rather than "OK" to ensure that your changes + are not overridden. + + + + +Common Errors + + +Stuff here + + + + + diff --git a/docs/docbook/projdoc/AdvancedNetworkAdmin.xml b/docs/docbook/projdoc/AdvancedNetworkAdmin.xml index dc2a78f5a67..e6e73472903 100644 --- a/docs/docbook/projdoc/AdvancedNetworkAdmin.xml +++ b/docs/docbook/projdoc/AdvancedNetworkAdmin.xml @@ -12,114 +12,6 @@ administrators who want to improve network resource access control, to automate environment, and to make their lives a little easier. - -Configuring Samba Share Access Controls - - -This section deals with how to configure Samba per share access control restrictions. -By default samba sets no restrictions on the share itself. Restrictions on the share itself -can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can -connect to a share. In the absence of specific restrictions the default setting is to allow -the global user Everyone Full Control (ie: Full control, Change and Read). - - - -At this time Samba does NOT provide a tool for configuring access control setting on the Share -itself. Samba does have the capacity to store and act on access control settings, but the only -way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for -Computer Management. - - - -Samba stores the per share access control settings in a file called share_info.tdb. -The location of this file on your system will depend on how samba was compiled. The default location -for samba's tdb files is under /usr/local/samba/var. If the tdbdump -utility has been compiled and installed on your system then you can examine the contents of this file -by: tdbdump share_info.tdb. - - - -Share Permissions Management - - -The best tool for the task is platform dependant. Choose the best tool for your environmemt. - - - -Windows NT4 Workstation/Server - -The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. -Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. -You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below. - - - -Instructions - -Launch the NT4 Server Manager, click on the Samba server you want to administer, then from the menu -select Computer, then click on the Shared Directories entry. - - - - Now click on the share that you wish to manage, then click on the Properties tab, next click on - the Permissions tab. Now you can Add or change access control settings as you wish. - - - - - - -Windows 200x/XP - - -On MS Windows NT4/200x/XP system access control lists on the share itself are set using native -tools, usually from filemanager. For example, in Windows 200x: right click on the shared folder, -then select 'Sharing', then click on 'Permissions'. The default Windows NT4/200x permission allows -Everyone Full Control on the Share. - - - -MS Windows 200x and later all comes with a tool called the 'Computer Management' snap-in for the -Microsoft Management Console (MMC). This tool is located by clicking on Control Panel -> -Administrative Tools -> Computer Management. - - - -Instructions - - After launching the MMC with the Computer Management snap-in, click on the menu item 'Action', - select 'Connect to another computer'. If you are not logged onto a domain you will be prompted - to enter a domain login user identifier and a password. This will authenticate you to the domain. - If you where already logged in with administrative privilidge this step is not offered. - - - -If the Samba server is not shown in the Select Computer box, then type in the name of the target -Samba server in the field 'Name:'. Now click on the [+] next to 'System Tools', then on the [+] -next to 'Shared Folders' in the left panel. - - - -Now in the right panel, double-click on the share you wish to set access control permissions on. -Then click on the tab 'Share Permissions'. It is now possible to add access control entities -to the shared folder. Do NOT forget to set what type of access (full control, change, read) you -wish to assign for each entry. - - - - - -Be careful. If you take away all permissions from the Everyone user without removing this user -then effectively no user will be able to access the share. This is a result of what is known as -ACL precidence. ie: Everyone with NO ACCESS means that MaryK who is part of the group Everyone -will have no access even if this user is given explicit full control access. - - - - - - - Remote Server Administration diff --git a/docs/docbook/projdoc/NT_Security.xml b/docs/docbook/projdoc/NT_Security.xml deleted file mode 100644 index 9bff25337c3..00000000000 --- a/docs/docbook/projdoc/NT_Security.xml +++ /dev/null @@ -1,335 +0,0 @@ - - - &author.jeremy; - 12 Apr 1999 - - -UNIX Permission Bits and Windows NT Access Control Lists - - - Viewing and changing UNIX permissions using the NT - security dialogs - - Windows NT clients can use their native security settings - dialog box to view and modify the underlying UNIX permissions. - - Note that this ability is careful not to compromise - the security of the UNIX host Samba is running on, and - still obeys all the file permission rules that a Samba - administrator can set. - - - - All access to Unix/Linux system file via Samba is controlled at - the operating system file access control level. When trying to - figure out file access problems it is vitally important to identify - the identity of the Windows user as it is presented by Samba at - the point of file access. This can best be determined from the - Samba log files. - - - - - - How to view file security on a Samba share - - From an NT4/2000/XP client, single-click with the right - mouse button on any file or directory in a Samba mounted - drive letter or UNC path. When the menu pops-up, click - on the Properties entry at the bottom of - the menu. This brings up the file properties dialog - box. Click on the tab Security and you - will see three buttons, Permissions, - Auditing, and Ownership. - The Auditing button will cause either - an error message A requested privilege is not held - by the client to appear if the user is not the - NT Administrator, or a dialog which is intended to allow an - Administrator to add auditing requirements to a file if the - user is logged on as the NT Administrator. This dialog is - non-functional with a Samba share at this time, as the only - useful button, the Add button will not currently - allow a list of users to be seen. - - - - - Viewing file ownership - - Clicking on the "Ownership" button - brings up a dialog box telling you who owns the given file. The - owner name will be of the form : - - "SERVER\user (Long name)" - - Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the descriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). Click on the Close - button to remove this dialog. - - If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone". - - The Take Ownership button will not allow - you to change the ownership of this file to yourself (clicking on - it will display a dialog box complaining that the user you are - currently logged onto the NT client cannot be found). The reason - for this is that changing the ownership of a file is a privileged - operation in UNIX, available only to the root - user. As clicking on this button causes NT to attempt to change - the ownership of a file to the current user logged into the NT - client this will not work with Samba at this time. - - There is an NT chown command that will work with Samba - and allow a user with Administrator privilege connected - to a Samba server as root to change the ownership of - files on both a local NTFS filesystem or remote mounted NTFS - or Samba drive. This is available as part of the Seclib - NT security library written by Jeremy Allison of - the Samba Team, available from the main Samba ftp site. - - - - - Viewing file or directory permissions - - The third button is the "Permissions" - button. Clicking on this brings up a dialog box that shows both - the permissions and the UNIX owner of the file or directory. - The owner is displayed in the form : - - "SERVER\user (Long name)" - - Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the descriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). - - If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone" and the - permissions will be shown as NT "Full Control". - - - The permissions field is displayed differently for files - and directories, so I'll describe the way file permissions - are displayed first. - - - File Permissions - - The standard UNIX user/group/world triple and - the corresponding "read", "write", "execute" permissions - triples are mapped by Samba into a three element NT ACL - with the 'r', 'w', and 'x' bits mapped into the corresponding - NT permissions. The UNIX world permissions are mapped into - the global NT group Everyone, followed - by the list of permissions allowed for UNIX world. The UNIX - owner and group permissions are displayed as an NT - user icon and an NT local - group icon respectively followed by the list - of permissions allowed for the UNIX user and group. - - As many UNIX permission sets don't map into common - NT names such as "read", - "change" or "full control" then - usually the permissions will be prefixed by the words - "Special Access" in the NT display list. - - But what happens if the file has no permissions allowed - for a particular UNIX user group or world component ? In order - to allow "no permissions" to be seen and modified then Samba - overloads the NT "Take Ownership" ACL attribute - (which has no meaning in UNIX) and reports a component with - no permissions as having the NT "O" bit set. - This was chosen of course to make it look like a zero, meaning - zero permissions. More details on the decision behind this will - be given below. - - - - Directory Permissions - - Directories on an NT NTFS file system have two - different sets of permissions. The first set of permissions - is the ACL set on the directory itself, this is usually displayed - in the first set of parentheses in the normal "RW" - NT style. This first set of permissions is created by Samba in - exactly the same way as normal file permissions are, described - above, and is displayed in the same way. - - The second set of directory permissions has no real meaning - in the UNIX permissions world and represents the - "inherited" permissions that any file created within - this directory would inherit. - - Samba synthesises these inherited permissions for NT by - returning as an NT ACL the UNIX permission mode that a new file - created by Samba on this share would receive. - - - - - Modifying file or directory permissions - - Modifying file and directory permissions is as simple - as changing the displayed permissions in the dialog box, and - clicking the OK button. However, there are - limitations that a user needs to be aware of, and also interactions - with the standard Samba permission masks and mapping of DOS - attributes that need to also be taken into account. - - If the parameter nt acl support - is set to false then any attempt to set - security permissions will fail with an "Access Denied" - message. - - The first thing to note is that the "Add" - button will not return a list of users in Samba (it will give - an error message of "The remote procedure call failed - and did not execute"). This means that you can only - manipulate the current user/group/world permissions listed in - the dialog box. This actually works quite well as these are the - only permissions that UNIX actually has. - - If a permission triple (either user, group, or world) - is removed from the list of permissions in the NT dialog box, - then when the "OK" button is pressed it will - be applied as "no permissions" on the UNIX side. If you then - view the permissions again the "no permissions" entry will appear - as the NT "O" flag, as described above. This - allows you to add permissions back to a file or directory once - you have removed them from a triple component. - - As UNIX supports only the "r", "w" and "x" bits of - an NT ACL then if other NT security attributes such as "Delete - access" are selected then they will be ignored when applied on - the Samba server. - - When setting permissions on a directory the second - set of permissions (in the second set of parentheses) is - by default applied to all files within that directory. If this - is not what you want you must uncheck the "Replace - permissions on existing files" checkbox in the NT - dialog before clicking "OK". - - If you wish to remove all permissions from a - user/group/world component then you may either highlight the - component and click the "Remove" button, - or set the component to only have the special "Take - Ownership" permission (displayed as "O" - ) highlighted. - - - - Interaction with the standard Samba create mask - parameters - - There are four parameters - to control interaction with the standard Samba create mask parameters. - These are : - - security mask - force security mode - directory security mask - force directory security mode - - Once a user clicks "OK" to apply the - permissions Samba maps the given permissions into a user/group/world - r/w/x triple set, and then will check the changed permissions for a - file against the bits set in the - security mask parameter. Any bits that - were changed that are not set to '1' in this parameter are left alone - in the file permissions. - - Essentially, zero bits in the security mask - mask may be treated as a set of bits the user is not - allowed to change, and one bits are those the user is allowed to change. - - - If not set explicitly this parameter is set to the same value as - the create mask - parameter. To allow a user to modify all the - user/group/world permissions on a file, set this parameter - to 0777. - - Next Samba checks the changed permissions for a file against - the bits set in the - force security mode parameter. Any bits - that were changed that correspond to bits set to '1' in this parameter - are forced to be set. - - Essentially, bits set in the force security mode - parameter may be treated as a set of bits that, when - modifying security on a file, the user has always set to be 'on'. - - If not set explicitly this parameter is set to the same value - as the force - create mode parameter. - To allow a user to modify all the user/group/world permissions on a file - with no restrictions set this parameter to 000. - - The security mask and force - security mode parameters are applied to the change - request in that order. - - For a directory Samba will perform the same operations as - described above for a file except using the parameter - directory security mask instead of security - mask, and force directory security mode - parameter instead of force security mode - . - - The directory security mask parameter - by default is set to the same value as the directory mask - parameter and the force directory security - mode parameter by default is set to the same value as - the force directory mode parameter. - - In this way Samba enforces the permission restrictions that - an administrator can set on a Samba share, whilst still allowing users - to modify the permission bits within that restriction. - - If you want to set up a share that allows users full control - in modifying the permission bits on their files and directories and - doesn't force any particular bits to be set 'on', then set the following - parameters in the &smb.conf; file in that share specific section : - - security mask = 0777 - force security mode = 0 - directory security mask = 0777 - force directory security mode = 0 - - - - Interaction with the standard Samba file attribute - mapping - - Samba maps some of the DOS attribute bits (such as "read - only") into the UNIX permissions of a file. This means there can - be a conflict between the permission bits set via the security - dialog and the permission bits set by the file attribute mapping. - - - One way this can show up is if a file has no UNIX read access - for the owner it will show up as "read only" in the standard - file attributes tabbed dialog. Unfortunately this dialog is - the same one that contains the security info in another tab. - - What this can mean is that if the owner changes the permissions - to allow themselves read access using the security dialog, clicks - "OK" to get back to the standard attributes tab - dialog, and then clicks "OK" on that dialog, then - NT will set the file permissions back to read-only (as that is what - the attributes still say in the dialog). This means that after setting - permissions and clicking "OK" to get back to the - attributes dialog you should always hit "Cancel" - rather than "OK" to ensure that your changes - are not overridden. - - - diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml index 8a582cf6e46..c6822303302 100644 --- a/docs/docbook/projdoc/samba-doc.xml +++ b/docs/docbook/projdoc/samba-doc.xml @@ -90,27 +90,28 @@ section carefully. Valuable Nuts and Bolts Information -Samba has several features that you might want or might not want to use. The chapters in this part each cover specific Samba features. +Samba has several features that you might want or might not want to use. +The chapters in this part each cover specific Samba features. &NetworkBrowsing; &Passdb; -&NT-Security; &GROUP-MAPPING-HOWTO; +&AccessControls; +&locking; +&SecuringSamba; +&Trusts; +&MS-Dfs-Setup; &PRINTER-DRIVER2; ∪︀ +&VFS; &WINBIND; &AdvancedNetworkAdmin; &PolicyMgmt; &ProfileMgmt; -&Trusts; &Samba-PAM; -&VFS; -&MS-Dfs-Setup; &IntegratingWithWindows; -&SecuringSamba; &unicode; -&locking; -- cgit