From d22215a033aec61675746570cbf24bee59f778be Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Fri, 4 Feb 2005 20:27:37 +0000 Subject: Adding patches and updats. (This used to be commit 249961a1959aa171e93b3e18d94bc69c07cbacdf) --- docs/Samba-HOWTO-Collection/AccessControls.xml | 61 ++++++++++++++++++++++++++ docs/Samba-HOWTO-Collection/PolicyMgmt.xml | 2 +- docs/Samba-HOWTO-Collection/ProfileMgmt.xml | 16 +++++++ 3 files changed, 78 insertions(+), 1 deletion(-) 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. + + Protecting Directories and Files from Deletion + + + 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 best fit + translation to POSIX ACLs. Some UNIX file systems do however support a feature known as extended attributes. Only + the Windows concept of inheritance is implemented by Samba through the appropriate extended attribute. + + + + 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 immutible bit. + Unfortunately, the implementation of the immutible flag is NOT consistent with published documentation. For example, the + man page for the chattr on SUSE Linux 9.2 says: + +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. + + 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. + o + + + + Create a file called filename + + + + Login as the root user, then set the immutibile flag on a test file as follows: + +&rootprompt; chatter +i 'filename' + + + + + Login as the user who owns the file (not root) attempt to remove the file as follows: + +mystic:/home/hannibal > rm filename + + It will not be possible to delete the file if the immutible flag is correctly honored. + + + + + 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. + + + + 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. 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 - + Implementing Profiles and Policies in Windows NT 4.0 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 Group Policies. 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 @@ -489,6 +489,22 @@ data and keeps it out of the desktop profile. That keeps desktop profiles from b + + User Profile Hive Cleanup Service + + +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 +UPHClean (User Profile Hive Cleanup) can be installed as service on Windows NT4/2000/XP Professional, +and Windows 2003. + + + +The UPHClean software package can be downloaded from User Profile Hive Cleanup Service + + + + Sharing Profiles between W9x/Me and NT4/200x/XP Workstations -- cgit