-
Notifications
You must be signed in to change notification settings - Fork 188
/
AuthFiles.html
181 lines (166 loc) · 9.42 KB
/
AuthFiles.html
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
<html>
<head>
<title>ProFTPD: Using AuthUserFiles</title>
</head>
<body bgcolor=white>
<hr>
<center><h2><b><i>ProFTPD: Using <code>AuthUserFile</code>s</i></b></h2></center>
<hr>
<p>
The FTP protocol is old, stemming from the days of Telnet, before security
came to be the relevant issue it is today. One of the protocol's biggest flaws,
in today's security-conscious world, is the transmission of passwords "in
the clear", unencrypted, easily visible to network sniffers. There
are several ways of attempting to deal with this flaw.
<p>
ProFTPD allows for the definition of "virtual" users: users who
do not have accounts on the host machine, whose account information is defined
in other sources. The passwords for these users are then specific only to
FTP access, and thus do not expose shell access (<code>ssh</code>, hopefully) to
unauthorized users. These alternative account information sources include SQL
tables (via <code>mod_sql</code>), LDAP servers (via <code>mod_ldap</code>),
CDB files (via <code>mod_auth_cdb</code>), and other system files (via
the
<a href="http://www.proftpd.org/docs/directives/linked/config_ref_AuthUserFile.html"><code>AuthUserFile</code></a> and
<a href="http://www.proftpd.org/docs/directives/linked/config_ref_AuthGroupFile.html"><code>AuthGroupFile</code></a>
configuration directives). The <code>proftpd</code> server can be configured
to use multiple account information sources simultaneously as well,
allowing for flexible support of a range of environments.
<p>
This document focuses on the use of the <code>AuthUserFile</code> and
<code>AuthGroupFile</code> directives. Several questions often arise
about the use of these directives. In general, the answers to those questions
apply to other authentication/account sources, too.
<p>
<b>Formats</b><br>
Any configured <code>AuthUserFile</code> is used <b>in addition to</b>
<code>/etc/passwd</code>, not <b>instead of</b> it (prior to 1.2.8rc1, however,
an <code>AuthUserFile</code> was used instead of <code>/etc/passwd</code>);
similarly for <code>AuthGroupFile</code> and <code>/etc/group</code>. The
<a href="Authentication.html#order"><code>AuthOrder</code></a> directive can be used if you want <code>proftpd</code> to use only the <code>AuthUserFile</code>.
The format of an <code>AuthUserFile</code> is the same as
<code>/etc/passwd</code> (<code>man passwd(5)</code>), and the format of an
<code>AuthGroupFile</code> is the same as <code>/etc/group</code> (<code>man
group(5)</code>). There is an <a href="../contrib/ftpasswd.html"><code>ftpasswd</code></a> script available that can be used to create and update
these files.
<p>
It is important to note here that not all flavors of Unix use these formats;
one notable exception is FreeBSD. With FreeBSD, user account information is
stored in binary database files as opposed to ASCII files. The C library on
this platform also lacks the functions necessary for making the
<code>AuthUserFile</code> and <code>AuthGroupFile</code> directives work
properly. In this case, <code>proftpd</code> uses an internal implementation
of the missing functions to read <code>AuthUserFile</code>s and
<code>AuthGroupFile</code>s. This internal implementation requires that
<code>AuthUserFile</code>s have the traditional <code>passwd(5)</code> format:
<pre>
username:password:uid:gid:gecos:homedir:shell
</pre>
and that <code>AuthGroupFile</code>s have this format:
<pre>
groupname:grouppasswd:gid:member1,member2,...member<i>N</i>
</pre>
The <a href="../contrib/ftpasswd.html"><code>ftpasswd</code></a> script
mentioned creates files in these required formats.
<p>
<b>Choice of IDs</b><br>
The choice of IDs for your users is important; the operating system does not
deal with user processes in terms of their user names, it knows only of the
numeric identity of a process. In general, it is best if each user has
a unique <i>positive</i> user ID (negative IDs are an ugly hack, and
<code>proftpd</code> will complain if they are used).
<p>
However, in some mass-hosting environments such as ISPs, the number of users
is greater than the number of IDs available. In these cases, you can give
each user the same ID; additional steps should then be taken to make sure
that each user is isolated from affecting other users' files. These additional
steps are to make sure each user has a unique home directory, and then
to restrict each user to their respective home directories by having
<pre>
DefaultRoot ~
</pre>
in your <code>proftpd.conf</code>.
<p>
<b>Shadow passwords</b><br>
There really is no need for an <code>AuthShadowFile</code> directive. The
purpose of a shadow file is separate sensitive information
(<i>e.g.</i> passwords) from other account information
(username/<code>UID</code>/<code>GID</code>, <i>etc</i>). Programs like
<code>/bin/ls</code> often reference the passwd file in order to display
user/group names rather than numbers; these programs do not really need that
sensitive information. Rather than relying on programs like
<code>/bin/ls</code> to ignore the sensitive information, libraries were
developed to split the information into <code>/etc/passwd</code>,
<code>/etc/shadow</code> (and similarly for <code>/etc/group</code>, but very
few administrators use group passwords anymore). Some operating systems, most
notably FreeBSD, though, chose a different form of information separation.
Since FreeBSD maintains account information in binary database files, the
shadow libraries mentioned above are not used. Instead, FreeBSD returns the
sensitive information to the calling program only if it has sufficient
(<i>i.e.</i> superuser) privileges.
<p>
When <code>proftpd</code> uses an <code>AuthUserFile</code>, it is looking for
all of the account information, including the password. And since
<code>AuthUserFile</code>s are specific to <code>proftpd</code>, there is no
need to split any passwords out of an <code>AuthUserFile</code> into an
<code>AuthShadowFile</code>. As the documentation states, an
<code>AuthUserFile</code> need not reside inside a <code>chroot()</code>
filesystem, which means that users can be effectively isolated from having
access to that <code>AuthUserFile</code>. At that point, the only
consideration is making sure that the permissions on the
<code>AuthUserFile</code> are sufficient for the server to have access, but
no other users.
<p>
<b>Permissions</b><br>
As the <code>AuthUserFile</code> and <code>AuthGroupFile</code> files are
meant to be drop-in replacements for their system cousins, there are a few
caveats. <code>/etc/passwd</code> and <code>/etc/group</code> are normally
world-readable on modern Unix systems. This allows programs like
<code>/bin/ls</code> to map system ID numbers to more legible names; sensitive
information in the <code>/etc/passwd</code> and <code>/etc/group</code>
is normally stored elsewhere, in restricted shadow files. The
<code>proftpd</code> server thus assumes that it will not need special
privileges to read an <code>AuthUserFile</code> or an
<code>AuthGroupFile</code>. The process will access any
<code>AuthUserFile</code>s and <code>AuthGroupFile</code>s with the credentials
of the user and group configured via the <code>User</code> and
<code>Group</code> directives. The files may contain sensitive information, so
they <b>should not</b> have as open of permissions as <code>/etc/passwd</code>
and <code>/etc/group</code>. The most paranoid setting will have
user-read-only permissions for those files, and have the files be owned by the
user configured for the relevant server via the <code>User</code> directive.
Hopefully the server administrator has created a new account on the system just
for the ftpd daemon.
<p>
<b>ID-to-name mapping</b><br>
A consequence of which to be aware when using an <code>AuthUserFile</code>
is the difference between that <code>AuthUserFile</code>'s mapping of
system IDs to names, and the mapping in <code>/etc/passwd</code>. This
may catch some system administrators unawares when they go to check the
ownership of files uploaded by some user whose account is defined in an
<code>AuthUserFile</code>, and find those files being reported as being
owned by different users and/or groups by <code>/bin/ls</code>. Keep in
mind that <code>/bin/ls</code> is using <code>/etc/passwd</code>, not
the <code>AuthUserFile</code>. This issue crops up with any alternative
account information source, not just <code>AuthUserFile</code>s.
<p>
If you are using the same UID/GID for your users, <i>e.g.</i> in a mass
hosting environment, one trick you might like to do is make all of the files,
as listed by the server, appear to be owned by the logged in user. This is
done using the <a href="http://www.proftpd.org/docs/directives/linked/config_ref_DirFakeUser.html"><code>DirFakeUser</code></a> and <a href="http://www.proftpd.org/docs/directives/linked/config_ref_DirFakeGroup.html"><code>DirFakeGroup</code></a> directives,
like this:
<pre>
# make listed files appear to be owned by the logged-in user
DirFakeUser on ~
DirFakeGroup on ~
</pre>
As noted in the documentation, these directives are purely cosmetic, and in
no way change the real ownership of files. This may cause some confusion on
the client side in some cases, if the user sees a file that is reported to be
owned by them, and the permissions on the file show user access is allowed, and
yet the client is unable to access the file. <a href="http://www.proftpd.org/docs/directives/linked/config_ref_HideNoAccess.html"><code>HideNoAccess</code></a>
can help in situations like this.
<p>
<hr>
</body>
</html>