summaryrefslogtreecommitdiff
path: root/docs/Samba-HOWTO-Collection
diff options
context:
space:
mode:
Diffstat (limited to 'docs/Samba-HOWTO-Collection')
-rw-r--r--docs/Samba-HOWTO-Collection/AccessControls.xml61
-rw-r--r--docs/Samba-HOWTO-Collection/PolicyMgmt.xml2
-rw-r--r--docs/Samba-HOWTO-Collection/ProfileMgmt.xml16
3 files changed, 78 insertions, 1 deletions
diff --git a/docs/Samba-HOWTO-Collection/AccessControls.xml b/docs/Samba-HOWTO-Collection/AccessControls.xml
index 3e933bf01b..f8f5d87ef0 100644
--- a/docs/Samba-HOWTO-Collection/AccessControls.xml
+++ b/docs/Samba-HOWTO-Collection/AccessControls.xml
@@ -402,6 +402,67 @@ drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08
group members will be able to write to (or delete) them.
</para>
+ <sect3>
+ <title>Protecting Directories and Files from Deletion</title>
+
+ <para>
+ People have asked on the Samba mailing list how is it possible to protect files or directories from deletion by users.
+ For example, Windows NT/2K/XP provides the capacity to set access controls on a directory into which people can
+ write files but not delete them. It is possible to set an ACL on a Windows file that permits the file to be written to
+ but not deleted. Such concepts are foreign to the UNIX operating system file space. Within the UNIX file system
+ anyone who has the ability to create a file can write to it, and has the capability to delete it. Of necessity, Samba
+ is subject to the file system semantics of the host operating system. Samba is therefore limited in the file system
+ capabilities that can be made available through Windows ACLs, and therefore performs a <quote>best fit</quote>
+ translation to POSIX ACLs. Some UNIX file systems do however support a feature known as extended attributes. Only
+ the Windows concept of <quote>inheritance</quote> is implemented by Samba through the appropriate extended attribute.
+ </para>
+
+ <para>
+ The specific semantics of the extended attributes are not consistent across UNIX and UNIX-like systems such as Linux.
+ For example, it is possible on some implementations of the extended attributes to set a flag that prevents the directory
+ or file from being deleted. The extended attribute that may achieve this is called the <constant>immutible</constant> bit.
+ Unfortunately, the implementation of the immutible flag is NOT consistent with published documentation. For example, the
+ man page for the <command>chattr</command> on SUSE Linux 9.2 says:
+<screen>
+A file with the‘i attribute cannot be modified: it cannot be deleted or renamed,
+no link can be created to this file and no data can be written to the file. Only
+the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set
+or clear this attribute.
+</screen>
+ A simple test can be done to check if the immutible flag is supported on files in the file system of the Samba host
+ server.
+ </para>o
+
+<procedure>
+ <step><para>
+ Create a file called <filename>filename</filename>
+ </para></step>
+
+ <step><para>
+ Login as the <constant>root</constant> user, then set the immutibile flag on a test file as follows:
+<screen>
+&rootprompt; chatter +i 'filename'
+</screen>
+ </para></step>
+
+ <step><para>
+ Login as the user who owns the file (not root) attempt to remove the file as follows:
+<screen>
+mystic:/home/hannibal > rm filename
+</screen>
+ It will not be possible to delete the file if the immutible flag is correctly honored.
+ </para></step>
+</procedure>
+
+ <para>
+ On those systems and file system types that support the immutible bit it is possible to create directories
+ that can not be deleted. Check the man page on your particular host system to determine whether or not
+ immutable directories are writable. If they are not, then the entire directory and its contents will effectively
+ by protected from writing (file creation also) and deletion.
+ </para>
+
+ </sect3>
+
</sect2>
</sect1>
diff --git a/docs/Samba-HOWTO-Collection/PolicyMgmt.xml b/docs/Samba-HOWTO-Collection/PolicyMgmt.xml
index 92cacd86ab..2f63148a58 100644
--- a/docs/Samba-HOWTO-Collection/PolicyMgmt.xml
+++ b/docs/Samba-HOWTO-Collection/PolicyMgmt.xml
@@ -99,7 +99,7 @@ be a step forward, but improved functionality comes at a great price.
<para>
Before embarking on the configuration of network and system policies, it is highly
advisable to read the documentation available from Microsoft's Web site regarding
-<ulink url="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp">
+<ulink url="http://www.microsoft.com/ntserver/techresources/management/prof_policies.asp">
Implementing Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft.
There are a large number of documents in addition to this old one that should also
be read and understood. Try searching on the Microsoft Web site for <quote>Group Policies</quote>.
diff --git a/docs/Samba-HOWTO-Collection/ProfileMgmt.xml b/docs/Samba-HOWTO-Collection/ProfileMgmt.xml
index f4a4ae64e7..e17f4b94a0 100644
--- a/docs/Samba-HOWTO-Collection/ProfileMgmt.xml
+++ b/docs/Samba-HOWTO-Collection/ProfileMgmt.xml
@@ -490,6 +490,22 @@ data and keeps it out of the desktop profile. That keeps desktop profiles from b
</sect2>
<sect2>
+ <title>User Profile Hive Cleanup Service</title>
+
+<para>
+There certain situations that cause a cached local copy of roaming profile not to be deleted on exit, even if
+the policy to force such deletion is set. To deal with that situation special service was created. The application
+<command>UPHClean</command> (User Profile Hive Cleanup) can be installed as service on Windows NT4/2000/XP Professional,
+and Windows 2003.
+</para>
+
+<para>
+The UPHClean software package can be downloaded from <ulink url="http://www.microsoft.com/downloads/details.aspx?FamilyID=1B286E6D-8912-4E18-B570-42470E2F3582&displaylang=en">User Profile Hive Cleanup Service</ulink>
+</para>
+
+</sect2>
+
+<sect2>
<title>Sharing Profiles between W9x/Me and NT4/200x/XP Workstations</title>
<para> Sharing of desktop profiles between Windows versions is not recommended. Desktop profiles are an