1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
<html>
<head>
<title>ProFTPD module mod_vroot</title>
</head>
<body bgcolor=white>
<hr>
<center>
<h2><b>ProFTPD module <code>mod_vroot</code></b></h2>
</center>
<hr><br>
This module is contained in the <code>mod_vroot.c</code> file for
ProFTPD 1.3.<i>x</i>, and is not compiled by default. Installation
instructions are discussed <a href="#Installation">here</a>.
<p>
The purpose of this module to is to implement a virtual chroot capability
that does not require root privileges. The <code>mod_vroot</code> module
provides this capability by using ProFTPD's FS API, available as of 1.2.8rc1.
<p>
The most current version of <code>mod_vroot</code> can be found at:
<pre>
<a href="https://github.com/Castaglia/proftpd-mod_vroot.git">https://github.com/Castaglia/proftpd-mod_vroot.git</a>
</pre>
<h2>Author</h2>
<p>
Please contact TJ Saunders <tj <i>at</i> castaglia.org> with any
questions, concerns, or suggestions regarding this module.
<h2>Thanks</h2>
<p>
<i>2003-08-26</i>: Thanks to Oskar Liljeblad for the elegant patch that added
symlink support.
<h2>Directives</h2>
<ul>
<li><a href="#VRootAlias">VRootAlias</a>
<li><a href="#VRootEngine">VRootEngine</a>
<li><a href="#VRootLog">VRootLog</a>
<li><a href="#VRootOptions">VRootOptions</a>
<li><a href="#VRootServerRoot">VRootServerRoot</a>
</ul>
<hr>
<h2><a name="VRootAlias">VRootAlias</a></h2>
<strong>Syntax:</strong> VRootAlias <em>src-path dst-path</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
<strong>Module:</strong> mod_vroot<br>
<strong>Compatibility:</strong> 1.3.2 and later
<p>
The <code>VRootAlias</code> directive is used to create an "alias" of a
directory outside of the chroot area into the chroot. The <em>dst-path</em>
parameter is a <b>relative</b> path, relative to the chroot area (<i>i.e.</i>
the directory in which the session starts). The <em>src-path</em> parameter,
on the other hand, is an <b>absolute</b> path, and may be to a file or
directory.
<p>
For example, you might map a shared upload directory into a user's home
directory using:
<pre>
<IfModule mod_vroot.c>
VRootEngine on
DefaultRoot ~
VRootAlias /var/ftp/upload ~/upload
</IfModule>
</pre>
This will automatically create an "upload" directory to appear in the
chroot area (in this case, the user's home directory).
<p>
The <code>VRootAlias</code> directive is only needed for files/directories
that are going to be accessed by remote clients. It is <b>not</b> needed
for configuration files (<i>e.g.</i> PAM configuration files like <code>pam_env.conf</code>) needed by libraries. Using the <code>VRootAlias</code> for
such library configuration files is pointless and wasteful.
<p>
Note that this directive will <b>not</b> work if the
<code>VRootServerRoot</code> is used.
<p>
<hr>
<h2><a name="VRootEngine">VRootEngine</a></h2>
<strong>Syntax:</strong> VRootEngine <em>on|off</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
<strong>Module:</strong> mod_vroot<br>
<strong>Compatibility:</strong> 1.2.8rc1 and later
<p>
The <code>VRootEngine</code> directive enables the virtual chroot engine
implemented by <code>mod_vroot</code>. If enabled, the virtual chroot will
be used in place of the operating system's <code>chroot(2)</code>. This
directive affects any <code>DefaultRoot</code> directives and any
<code><Anonymous></code> contexts within the server context in which
the <code>VRootEngine</code> directive appears.
<p>
<hr>
<h2><a name="VRootLog">VRootLog</a></h2>
<strong>Syntax:</strong> VRootLog <em>file</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
<strong>Module:</strong> mod_vroot<br>
<strong>Compatibility:</strong> 1.3.0rc1 and later
<p>
The <code>VRootLog</code> directive is used to specify a log file for
<code>mod_vroot</code>'s reporting on a per-server basis. The <em>file</em>
parameter given must be the full path to the file to use for logging.
<p>
<hr>
<h2><a name="VRootOptions">VRootOptions</a></h2>
<strong>Syntax:</strong> VRootOptions <em>opt1 ...</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> "server config" <code><VirtualHost></code>, <code><Global></code><br>
<strong>Module:</strong> mod_vroot<br>
<strong>Compatibility:</strong> 1.2.9rc2 and later
<p>
The <code>VRootOptions</code> directive is used to configure various optional
behavior of <code>mod_vroot</code>.
<p>
Example:
<pre>
VRootOptions allowSymlinks
</pre>
<p>
The currently implemented options are:
<ul>
<li><code>allowSymlinks</code><br>
<p>
Normally, any symlinks that point outside of the vroot area simply do
not work. When the <code>allowSymlinks</code> option is enabled, these
symlinks will be allowed. Note that by enabling symlinks, the efficacy
of the vroot "jail" is reduced.
</li>
</ul>
<p>
<hr>
<h2><a name="VRootServerRoot">VRootServerRoot</a></h2>
<strong>Syntax:</strong> VRootServerRoot <em>path</em><br>
<strong>Default:</strong> None<br>
<strong>Context:</strong> "server config" <code><VirtualHost></code>, <code><Global></code><br>
<strong>Module:</strong> mod_vroot<br>
<strong>Compatibility:</strong> 1.3.2rc1 and later
<p>
The <code>VRootServerRoot</code> directive is used to configure a directory
to which the <code>mod_vroot</code> module will perform a <i>real</i> chroot.
The idea is that each <code><VirtualHost></code> can have its own
directory to which a real <code>chroot(2)</code> system call is made;
the user-specific home directories will be virtual roots underneath this
directory. Thus some measure of security, via the <code>chroot(2)</code>
system call, is provided by the kernel, while still allowing symlinked shared
folders among users of this <code><VirtualHost></code>.
<p>
For example:
<pre>
<VirtualHost a.b.c.d>
VRootEngine on
VRootServerRoot /etc/ftpd/a.b.c.d/
VRootOptions allowSymlinks
DefaultRoot ~
...
</VirtualHost>
</pre>
<p>
See also: <a href="#VRootOptions"><code>VRootOptions</code></a>
<p>
<hr>
<h2><a name="Installation">Installation</a></h2>
To install <code>mod_vroot</code>, go to the third-party module area in
the proftpd source code and unpack the <code>mod_vroot</code> source tarball:
<pre>
$ cd <i>proftpd-dir</i>/contrib/
$ tar zxvf /path/to/mod_vroot-<i>version</i>.tar.gz
</pre>
after unpacking the latest proftpd-1.3.<i>x</i> source code. For including
<code>mod_vroot</code> as a staticly linked module:
<pre>
$ ./configure --with-modules=mod_vroot:...
</pre>
To build <code>mod_vroot</code> as a DSO module:
<pre>
$ ./configure --enable-dso --with-shared=mod_vroot:...
</pre>
Then follow the usual steps:
<pre>
$ make
$ make install
</pre>
<p>
<hr>
<font size=2><b><i>
© Copyright 2000-2016 TJ Saunders<br>
All Rights Reserved<br>
</i></b></font>
<hr>
</body>
</html>
|
