~zulcss/samba/server-dailies-3.4

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�16.�File, Directory, and Share Access Controls</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="The Official Samba 3.4.x HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part�III.�Advanced Configuration"><link rel="prev" href="rights.html" title="Chapter�15.�User Rights and Privileges"><link rel="next" href="locking.html" title="Chapter�17.�File and Record Locking"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�16.�File, Directory, and Share Access Controls</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="rights.html">Prev</a>�</td><th width="60%" align="center">Part�III.�Advanced Configuration</th><td width="20%" align="right">�<a accesskey="n" href="locking.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="AccessControls"></a>Chapter�16.�File, Directory, and Share Access Controls</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="orgname">Samba Team</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="orgname">Samba Team</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jra@samba.org">jra@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="orgname">The Samba Team</span> <span class="surname">Vernooij</span></h3><span class="contrib">drawing</span>�<div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:jelmer@samba.org">jelmer@samba.org</a>></code></p></div></div></div></div><div><p class="pubdate">May 10, 2003</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="AccessControls.html#id2610564">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="AccessControls.html#id2610751">File System Access Controls</a></span></dt><dd><dl><dt><span class="sect2"><a href="AccessControls.html#id2610766">MS Windows NTFS Comparison with UNIX File Systems</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2611102">Managing Directories</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2611225">File and Directory Access Control</a></span></dt></dl></dd><dt><span class="sect1"><a href="AccessControls.html#id2611896">Share Definition Access Controls</a></span></dt><dd><dl><dt><span class="sect2"><a href="AccessControls.html#id2611929">User- and Group-Based Controls</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2612297">File and Directory Permissions-Based Controls</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2612634">Miscellaneous Controls</a></span></dt></dl></dd><dt><span class="sect1"><a href="AccessControls.html#id2612972">Access Controls on Shares</a></span></dt><dd><dl><dt><span class="sect2"><a href="AccessControls.html#id2613120">Share Permissions Management</a></span></dt></dl></dd><dt><span class="sect1"><a href="AccessControls.html#id2613466">MS Windows Access Control Lists and UNIX Interoperability</a></span></dt><dd><dl><dt><span class="sect2"><a href="AccessControls.html#id2613473">Managing UNIX Permissions Using NT Security Dialogs</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2613520">Viewing File Security on a Samba Share</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2613591">Viewing File Ownership</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2613735">Viewing File or Directory Permissions</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2613950">Modifying File or Directory Permissions</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2614107">Interaction with the Standard Samba create mask Parameters</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2614477">Interaction with the Standard Samba File Attribute Mapping</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2614550">Windows NT/200X ACLs and POSIX ACLs Limitations</a></span></dt></dl></dd><dt><span class="sect1"><a href="AccessControls.html#id2614968">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="AccessControls.html#id2614980">Users Cannot Write to a Public Share</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2615303">File Operations Done as root with force user Set</a></span></dt><dt><span class="sect2"><a href="AccessControls.html#id2615348">MS Word with Samba Changes Owner of File</a></span></dt></dl></dd></dl></div><p>

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

administrators are often confused regarding network access controls and how to

provide users with the access they need while protecting resources from unauthorized access.

</p><p>

Many UNIX administrators are unfamiliar 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.

</p><p>

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 cannot completely hide, even

though it does try to bridge the chasm to a degree.

</p><p>

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.

</p><p>

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.

</p><p>

This is an opportune point to mention that Samba was created to provide a means of interoperability

and interchange of data between differing operating environments. Samba has no intent to change

UNIX/Linux into a platform like MS Windows. Instead the purpose was and is to provide a sufficient

level of exchange of data between the two environments. What is available today extends well

beyond early plans and expectations, yet the gap continues to shrink.

</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2610564"></a>Features and Benefits</h2></div></div></div><p>

Samba offers much flexibility in file system access management. These are the key access control

facilities present in Samba today:

</p><div class="itemizedlist"><p class="title"><b>Samba Access Control Facilities</b></p><ul type="disc"><li><p>

<span class="emphasis"><em>UNIX File and Directory Permissions</em></span>

</p><p>

Samba honors and implements UNIX file system access controls. Users

who access a Samba server will do so as a particular MS Windows user.

This information is passed to the Samba server as part of the logon or

connection setup process. Samba uses this user identity to validate

whether or not the user should be given access to file system resources

(files and directories). This chapter provides an overview for those

to whom the UNIX permissions and controls are a little strange or unknown.

</p></li><li><p>

<span class="emphasis"><em>Samba Share Definitions</em></span>

</p><p>

In configuring share settings and controls in the <code class="filename">smb.conf</code> file,

the network administrator can exercise overrides to native file

system permissions and behaviors. This can be handy and convenient

to effect behavior that is more like what MS Windows NT users expect,

but it is seldom the <span class="emphasis"><em>best</em></span> way to achieve this.

The basic options and techniques are described herein.

</p></li><li><p>

<span class="emphasis"><em>Samba Share ACLs</em></span>

</p><p>

Just as it is possible in MS Windows NT to set ACLs on shares

themselves, so it is possible to do in Samba.

Few people make use of this facility, yet it remains one of the

easiest ways to affect access controls (restrictions) and can often

do so with minimum invasiveness compared with other methods.

</p></li><li><p>

<span class="emphasis"><em>MS Windows ACLs through UNIX POSIX ACLs</em></span>

</p><p>

The use of POSIX ACLs on UNIX/Linux is possible only if the underlying

operating system supports them. If not, then this option will not be

available to you. Current UNIX technology platforms have native support

for POSIX ACLs. There are patches for the Linux kernel that also provide

this support. Sadly, few Linux platforms ship today with native ACLs and

extended attributes enabled. This chapter has pertinent information

for users of platforms that support them.

</p></li></ul></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2610751"></a>File System Access Controls</h2></div></div></div><p>

Perhaps the most important recognition to be made is the simple fact that MS Windows NT4/200x/XP

implement a totally divergent file system technology from what is provided in the UNIX operating system

100

environment. First we consider what the most significant differences are, then we look

101

at how Samba helps to bridge the differences.

102

</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2610766"></a>MS Windows NTFS Comparison with UNIX File Systems</h3></div></div></div><p>

103

104

105

106

107

Samba operates on top of the UNIX file system. This means it is subject to UNIX file system conventions

108

and permissions. It also means that if the MS Windows networking environment requires file system

109

behavior, that differs from UNIX file system behavior then somehow Samba is responsible for emulating

110

that in a transparent and consistent manner.

111

</p><p>

112

It is good news that Samba does this to a large extent, and on top of that, provides a high degree

113

of optional configuration to override the default behavior. We look at some of these overrides,

114

but for the greater part we stay within the bounds of default behavior. Those wishing to explore

115

the depths of control ability should review the <code class="filename">smb.conf</code> man page.

116

</p><p>The following compares file system features for UNIX with those of MS Windows NT/200x:

117

118

119

</p><div class="variablelist"><dl><dt><span class="term">Name Space</span></dt><dd><p>

120

MS Windows NT4/200x/XP file names may be up to 254 characters long, and UNIX file names

121

may be 1023 characters long. In MS Windows, file extensions indicate particular file types;

122

in UNIX this is not so rigorously observed because all names are considered arbitrary.

123

</p><p>

124

What MS Windows calls a folder, UNIX calls a directory.

125

</p></dd><dt><span class="term">Case Sensitivity</span></dt><dd><p>

126

127

128

MS Windows file names are generally uppercase if made up of 8.3 (8-character file name

129

and 3 character extension. File names that are longer than 8.3 are case preserving and case

130

insensitive.

131

</p><p>

132

UNIX file and directory names are case sensitive and case preserving. Samba implements the

133

MS Windows file name behavior, but it does so as a user application. The UNIX file system

134

provides no mechanism to perform case-insensitive file name lookups. MS Windows does this

135

by default. This means that Samba has to carry the processing overhead to provide features

136

that are not native to the UNIX operating system environment.

137

</p><p>

138

Consider the following. All are unique UNIX names but one single MS Windows file name:

139

</p><pre class="screen">

140

MYFILE.TXT

141

MyFile.txt

142

myfile.txt

143

</pre><p>

144

So clearly, in an MS Windows file namespace these three files cannot co-exist, but in UNIX

145

they can.

146

</p><p>

147

So what should Samba do if all three are present? That which is lexically first will be

148

accessible to MS Windows users; the others are invisible and unaccessible any

149

other solution would be suicidal. The Windows client will ask for a case-insensitive file

150

lookup, and that is the reason for which Samba must offer a consistent selection in the

151

event that the UNIX directory contains multiple files that would match a case insensitive

152

file listing.

153

</p></dd><dt><span class="term">Directory Separators</span></dt><dd><p>

154

155

MS Windows and DOS use the backslash <code class="constant">\</code> as a directory delimiter, and UNIX uses

156

the forward-slash <code class="constant">/</code> as its directory delimiter. This is handled transparently by Samba.

157

</p></dd><dt><span class="term">Drive Identification</span></dt><dd><p>

158

159

MS Windows products support a notion of drive letters, like <code class="literal">C:</code>, to represent

160

disk partitions. UNIX has no concept of separate identifiers for file partitions; each

161

such file system is mounted to become part of the overall directory tree.

162

The UNIX directory tree begins at <code class="constant">/</code> just as the root of a DOS drive is specified as

163

<code class="constant">C:\</code>.

164

</p></dd><dt><span class="term">File Naming Conventions</span></dt><dd><p>

165

166

MS Windows generally never experiences file names that begin with a dot (<code class="constant">.</code>), while in UNIX these

167

are commonly found in a user's home directory. Files that begin with a dot (<code class="constant">.</code>) are typically

168

startup files for various UNIX applications, or they may be files that contain

169

startup configuration data.

170

</p></dd><dt><span class="term">Links and Short-Cuts</span></dt><dd><p>

171

172

173

174

MS Windows make use of <span class="emphasis"><em>links and shortcuts</em></span> that are actually special types of files that will

175

redirect an attempt to execute the file to the real location of the file. UNIX knows of file and directory

176

links, but they are entirely different from what MS Windows users are used to.

177

</p><p>

178

Symbolic links are files in UNIX that contain the actual location of the data (file or directory). An

179

operation (like read or write) will operate directly on the file referenced. Symbolic links are also

180

referred to as “<span class="quote">soft links.</span>” A hard link is something that MS Windows is not familiar with. It allows

181

one physical file to be known simultaneously by more than one file name.

182

</p></dd></dl></div><p>

183

There are many other subtle differences that may cause the MS Windows administrator some temporary discomfort

184

in the process of becoming familiar with UNIX/Linux. These are best left for a text that is dedicated to the

185

purpose of UNIX/Linux training and education.

186

</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2611102"></a>Managing Directories</h3></div></div></div><p>

187

188

189

190

There are three basic operations for managing directories: <code class="literal">create</code>, <code class="literal">delete</code>,

191

<code class="literal">rename</code>. <a class="link" href="AccessControls.html#TOSH-Accesstbl" title="Table�16.1.�Managing Directories with UNIX and Windows">Managing Directories with UNIX and

192

Windows</a> compares the commands in Windows and UNIX that implement these operations.

193

</p><div class="table"><a name="TOSH-Accesstbl"></a><p class="title"><b>Table�16.1.�Managing Directories with UNIX and Windows</b></p><div class="table-contents"><table summary="Managing Directories with UNIX and Windows" border="1"><colgroup><col><col><col></colgroup><thead><tr><th align="center">Action</th><th align="center">MS Windows Command</th><th align="center">UNIX Command</th></tr></thead><tbody><tr><td align="center">create</td><td align="center">md folder</td><td align="center">mkdir folder</td></tr><tr><td align="center">delete</td><td align="center">rd folder</td><td align="center">rmdir folder</td></tr><tr><td align="center">rename</td><td align="center">rename oldname newname</td><td align="center">mv oldname newname</td></tr></tbody></table></div></div><br class="table-break"></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2611225"></a>File and Directory Access Control</h3></div></div></div><p>

194

195

196

197

The network administrator is strongly advised to read basic UNIX training manuals and reference materials

198

regarding file and directory permissions maintenance. Much can be achieved with the basic UNIX permissions

199

without having to resort to more complex facilities like POSIX ACLs or extended attributes (EAs).

200

</p><p>

201

UNIX/Linux file and directory access permissions involves setting three primary sets of data and one control set.

202

A UNIX file listing looks as follows:

203

</p><pre class="screen">

204

205

total 632

206

drwxr-xr-x 13 maryo gnomes 816 2003-05-12 22:56 .

207

drwxrwxr-x 37 maryo gnomes 3800 2003-05-12 22:29 ..

208

dr-xr-xr-x 2 maryo gnomes 48 2003-05-12 22:29 muchado02

209

drwxrwxrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado03

210

drw-rw-rw- 2 maryo gnomes 48 2003-05-12 22:29 muchado04

211

d-w--w--w- 2 maryo gnomes 48 2003-05-12 22:29 muchado05

212

dr--r--r-- 2 maryo gnomes 48 2003-05-12 22:29 muchado06

213

drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08

214

---------- 1 maryo gnomes 1242 2003-05-12 22:31 mydata00.lst

215

--w--w--w- 1 maryo gnomes 7754 2003-05-12 22:33 mydata02.lst

216

-r--r--r-- 1 maryo gnomes 21017 2003-05-12 22:32 mydata04.lst

217

-rw-rw-rw- 1 maryo gnomes 41105 2003-05-12 22:32 mydata06.lst

218

219

</pre><p>

220

</p><p>

221

The columns represent (from left to right) permissions, number of hard links to file, owner, group, size

222

(bytes), access date, time of last modification, and file name.

223

</p><p>

224

An overview of the permissions field is shown in <a class="link" href="AccessControls.html#access1" title="Figure�16.1.�Overview of UNIX permissions field.">Overview of UNIX permissions

225

field</a>.

226

</p><div class="figure"><a name="access1"></a><p class="title"><b>Figure�16.1.�Overview of UNIX permissions field.</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/access1.png" width="216" alt="Overview of UNIX permissions field."></div></div></div><br class="figure-break"><p>

227

Any bit flag may be unset. An unset bit flag is the equivalent of "cannot" and is represented

228

as a “<span class="quote">-</span>” character (see <a class="link" href="AccessControls.html#access2" title="Example�16.1.�Example File">“Example File”</a>)

229

230

231

232

233

234

235

</p><div class="example"><a name="access2"></a><p class="title"><b>Example�16.1.�Example File</b></p><div class="example-contents"><pre class="programlisting">

236

-rwxr-x--- Means:

237

^^^ The owner (user) can read, write, execute

238

^^^ the group can read and execute

239

^^^ everyone else cannot do anything with it.

240

</pre></div></div><br class="example-break"><p>

241

242

243

244

245

Additional possibilities in the [type] field are c = character device, b = block device, p = pipe device,

246

s = UNIX Domain Socket.

247

</p><p>

248

249

250

251

252

253

The letters <code class="constant">rwxXst</code> set permissions for the user, group, and others as read (r), write (w),

254

execute (or access for directories) (x), execute only if the file is a directory or already has execute

255

permission for some user (X), set user (SUID) or group ID (SGID) on execution (s), sticky (t).

256

</p><p>

257

258

259

260

261

When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner.

262

Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on

263

directories, such as <code class="filename">/tmp</code>, that are world-writable.

264

</p><p>

265

266

267

268

269

270

When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or

271

group whose `set user or group' bit is set. This can be helpful in setting up directories for which it is desired that

272

all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file

273

to be exclusively owned by a user whose primary group is not the group that all such users belong to.

274

</p><p>

275

When a directory is set <code class="constant">d-wx--x---</code>, the owner can read and create (write) files in it, but because

276

the (r) read flags are not set, files cannot be listed (seen) in the directory by anyone. The group can read files in the

277

directory but cannot create new files. If files in the directory are set to be readable and writable for the group, then

278

group members will be able to write to (or delete) them.

279

</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2611642"></a>Protecting Directories and Files from Deletion</h4></div></div></div><p>

280

281

282

283

284

People have asked on the Samba mailing list how is it possible to protect files or directories from deletion by users.

285

For example, Windows NT/2K/XP provides the capacity to set access controls on a directory into which people can

286

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

287

but not deleted. Such concepts are foreign to the UNIX operating system file space. Within the UNIX file system

288

anyone who has the ability to create a file can write to it. Anyone who has write permission on the

289

directory that contains a file and has write permission for it has the capability to delete it.

290

</p><p>

291

292

293

294

For the record, in the UNIX environment the ability to delete a file is controlled by the permissions on

295

the directory that the file is in. In other words, a user can delete a file in a directory to which that

296

user has write access, even if that user does not own the file.

297

</p><p>

298

299

300

301

302

Of necessity, Samba is subject to the file system semantics of the host operating system. Samba is therefore

303

limited in the file system capabilities that can be made available through Windows ACLs, and therefore performs

304

a "best fit" translation to POSIX ACLs. Some UNIX file systems do, however support, a feature known

305

as extended attributes. Only the Windows concept of <span class="emphasis"><em>inheritance</em></span> is implemented by Samba through

306

the appropriate extended attribute.

307

</p><p>

308

309

310

311

312

The specific semantics of the extended attributes are not consistent across UNIX and UNIX-like systems such as Linux.

313

For example, it is possible on some implementations of the extended attributes to set a flag that prevents the directory

314

or file from being deleted. The extended attribute that may achieve this is called the <code class="constant">immutible</code> bit.

315

Unfortunately, the implementation of the immutible flag is NOT consistent with published documentation. For example, the

316

man page for the <code class="literal">chattr</code> on SUSE Linux 9.2 says:

317

</p><pre class="screen">

318

A file with the i attribute cannot be modified: it cannot be deleted

319

or renamed, no link can be created to this file and no data can be

320

written to the file. Only the superuser or a process possessing the

321

CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

322

</pre><p>

323

A simple test can be done to check if the immutible flag is supported on files in the file system of the Samba host

324

server.

325

</p><div class="procedure"><a name="id2611823"></a><p class="title"><b>Procedure�16.1.�Test for File Immutibility Support</b></p><ol type="1"><li><p>

326

Create a file called <code class="filename">filename</code>.

327

</p></li><li><p>

328

329

</p><pre class="screen">

330

<code class="prompt">root# </code> chattr +i `filename'

331

</pre><p>

332

</p></li><li><p>

333

334

</p><pre class="screen">

335

mystic:/home/hannibal > rm filename

336

</pre><p>

337

It will not be possible to delete the file if the immutible flag is correctly honored.

338

</p></li></ol></div><p>

339

On operating systems and file system types that support the immutible bit, it is possible to create directories

340

that cannot be deleted. Check the man page on your particular host system to determine whether or not

341

immutable directories are writable. If they are not, then the entire directory and its contents will effectively

342

be protected from writing (file creation also) and deletion.

343

</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2611896"></a>Share Definition Access Controls</h2></div></div></div><p>

344

345

The following parameters in the <code class="filename">smb.conf</code> file sections define a share control or affect access controls.

346

Before using any of the following options, please refer to the man page for <code class="filename">smb.conf</code>.

347

</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2611929"></a>User- and Group-Based Controls</h3></div></div></div><p>

348

User- and group-based controls can prove quite useful. In some situations it is distinctly desirable to

349

force all file system operations as if a single user were doing so. The use of the

350

<a class="link" href="smb.conf.5.html#FORCEUSER" target="_top">force user</a> and <a class="link" href="smb.conf.5.html#FORCEGROUP" target="_top">force group</a> behavior will achieve this.

351

In other situations it may be necessary to use a paranoia level of control to ensure that only particular

352

authorized persons will be able to access a share or its contents. Here the use of the

353

<a class="link" href="smb.conf.5.html#VALIDUSERS" target="_top">valid users</a> or the <a class="link" href="smb.conf.5.html#INVALIDUSERS" target="_top">invalid users</a> parameter may be useful.

354

</p><p>

355

As always, it is highly advisable to use the easiest to maintain and the least ambiguous method for

356

controlling access. Remember, when you leave the scene, someone else will need to provide assistance, and

357

if he or she finds too great a mess or does not understand what you have done, there is risk of

358

Samba being removed and an alternative solution being adopted.

359

</p><p>

360

<a class="link" href="AccessControls.html#ugbc" title="Table�16.2.�User- and Group-Based Controls">User and Group Based Controls</a> enumerates these controls.

361

</p><div class="table"><a name="ugbc"></a><p class="title"><b>Table�16.2.�User- and Group-Based Controls</b></p><div class="table-contents"><table summary="User- and Group-Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description, Action, Notes</th></tr></thead><tbody><tr><td align="left"><a class="link" href="smb.conf.5.html#ADMINUSERS" target="_top">admin users</a></td><td align="justify"><p>

362

List of users who will be granted administrative privileges on the share.

363

They will do all file operations as the superuser (root).

364

Users in this list will be able to do anything they like on the share,

365

irrespective of file permissions.

366

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#FORCEGROUP" target="_top">force group</a></td><td align="justify"><p>

367

Specifies a UNIX group name that will be assigned as the default primary group

368

for all users connecting to this service.

369

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#FORCEUSER" target="_top">force user</a></td><td align="justify"><p>

370

Specifies a UNIX username that will be assigned as the default user for all users connecting to this service.

371

This is useful for sharing files. Incorrect use can cause security problems.

372

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#GUESTOK" target="_top">guest ok</a></td><td align="justify"><p>

373

If this parameter is set for a service, then no password is required to connect to the service. Privileges will be

374

those of the guest account.

375

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#INVALIDUSERS" target="_top">invalid users</a></td><td align="justify"><p>

376

List of users that should not be allowed to login to this service.

377

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#ONLYUSER" target="_top">only user</a></td><td align="justify"><p>

378

Controls whether connections with usernames not in the user list will be allowed.

379

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#READLIST" target="_top">read list</a></td><td align="justify"><p>

380

List of users that are given read-only access to a service. Users in this list

381

will not be given write access, no matter what the read-only option is set to.

382

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#USERNAME" target="_top">username</a></td><td align="justify"><p>

383

Refer to the <code class="filename">smb.conf</code> man page for more information; this is a complex and potentially misused parameter.

384

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#VALIDUSERS" target="_top">valid users</a></td><td align="justify"><p>

385

List of users that should be allowed to login to this service.

386

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#WRITELIST" target="_top">write list</a></td><td align="justify"><p>

387

List of users that are given read-write access to a service.

388

</p></td></tr></tbody></table></div></div><br class="table-break"></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2612297"></a>File and Directory Permissions-Based Controls</h3></div></div></div><p>

389

Directory permission-based controls, if misused, can result in considerable difficulty in diagnosing the causes of

390

misconfiguration. Use them sparingly and carefully. By gradually introducing each, one at a time, undesirable side

391

effects may be detected. In the event of a problem, always comment all of them out and then gradually reintroduce

392

them in a controlled way.

393

</p><p>

394

Refer to <a class="link" href="AccessControls.html#fdpbc" title="Table�16.3.�File and Directory Permission-Based Controls">File and Directory Permission Based Controls</a> for information

395

regarding the parameters that may be used to set file and directory permission-based access controls.

396

</p><div class="table"><a name="fdpbc"></a><p class="title"><b>Table�16.3.�File and Directory Permission-Based Controls</b></p><div class="table-contents"><table summary="File and Directory Permission-Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description, Action, Notes</th></tr></thead><tbody><tr><td align="left"><a class="link" href="smb.conf.5.html#CREATEMASK" target="_top">create mask</a></td><td align="justify"><p>

397

Refer to the <code class="filename">smb.conf</code> man page.

398

</p></td></tr><tr><td align="left"><a class="link" href="smb.conf.5.html#DIRECTORYMASK" target="_top">directory mask</a></td><td align="justify"><p>

399

The octal modes used when converting DOS modes to UNIX modes when creating UNIX directories.

400