sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2024-12-27 03:21:53 +03:00
Code

Adding patches and updats.

Browse Source
This commit is contained in:
John Terpstra 2005-02-04 20:27:37 +00:00 committed by Gerald W. Carter
parent 4524d2c761
commit 249961a195
3 changed files with 78 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
docs/Samba-HOWTO-Collection/AccessControls.xml
View File

@ -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>

2
docs/Samba-HOWTO-Collection/PolicyMgmt.xml
View File

@ -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>.

16
docs/Samba-HOWTO-Collection/ProfileMgmt.xml
View File

@ -489,6 +489,22 @@ data and keeps it out of the desktop profile. That keeps desktop profiles from b
</sect3>
</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>