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
|
Here's how permissions (and other things) are implemented:
Permissions can be divided into several groups:
* login
if login_pre_ip_check is enabled, check the user ip just after connection
if tls_mode is explicit, switch the connection to tls
send the welcome message
check the user name (in the backend)
check if ip is allowed for this user (backend)
wait next command:
+ AUTH check if user is allowed to use explicit mode (backend)
+ PASS check pass, check if user is using the correct mode (you can force
users to use or not explicit mode in backend)
check if user can chdir to his home dir
* command permissions
they are usually set in the config file (wzd.cfg) using directives like:
-delete =admin -toto
site commands are threated like other commands, replace spaces by _
-site_uptime =admin
ORDER IS IMPORTANT !!!
if someone complains about something like -command = !* =user
-> kickban !
* fxp (aka site-to-site transfer)
if user_ip != data_ip :
+ if data_ip is allowed for this user, ok
+ if user is allowed to fxp (config file directive: fxp) ok
* file permissions
There are many possibilities, checked IN THAT ORDER :
- if there is a permission file in the dir (.dirinfo for the moment, could change), look in that file:
+ If the user name is present, apply corresponding acl
+ If the user is the owner of file, apply owner_default_perm (config file) (TODO: implement me !)
+ If the user is from group of file, apply group_default_perm (config file) (TODO: implement me !)
- apply user default perms (user config file, depends on the backend)
* site commands
as written some lines above (commands permissions):
--
site commands are threated like other commands, replace spaces by _
-site_uptime =admin
--
|
