[Proftpd-user] chroot after rewriting home dir doesn't work as expected

Discussion:

Alex Domoradov

2016-02-23 22:41:08 UTC

Hello,

I'm using the following settings with ProFTPD 1.3.5a

<VirtualHost sftp.example.net>
ServerName "SFTP: Backup server."
DefaultRoot ~
Umask 002
Port 2121

RootRevoke on

AuthUserFile /etc/proftpd/sftp_virtual_users.conf

SFTPEngine on
SFTPLog /var/log/proftpd/sftp.log
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key
SFTPAuthorizedUserKeys file:/etc/proftpd/sftp_users
SFTPCompression delayed
SFTPAuthMethods publickey
SFTPDHParamFile /etc/pki/proftpd/dhparam_2048.pem

RewriteHome on
RewriteEngine on
RewriteLog /var/log/proftpd/rewrite.log
RewriteCondition %m REWRITE_HOME
RewriteRule (.*) /vhosts/backup/%U
</VirtualHost>

The password file contain only one line

# cat /etc/proftpd/sftp_virtual_users.conf
user1:{HASH}:99:99::/vhosts/backup/:/sbin/nologin

according to a log files

2016-02-23 22:32:46,871 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): mod_cap/1.1: adding CAP_SETUID and CAP_SETGID
capabilities
2016-02-23 22:32:46,871 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): SSH2 session opened.
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Preparing to chroot to directory
'/vhosts/backup/user1'
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): USER user1: Login successful
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to seteuid(): Operation
not permitted
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): RootRevoke in effect, dropped root privs
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): USER user1: Login successful.

2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_match_cond():
checking regex cond against 'REWRITE_HOME'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_fixup(): condition
met
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_fixup(): executing
RewriteRule
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): original
pattern: '/vhosts/backup/%U'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): rule
backref subst'd pattern: '/vhosts/backup/%U'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): pattern
'/vhosts/backup/%U' had no cond backrefs
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst_vars():
replacing variable '%U' with 'user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): var
subst'd pattern: '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_parse_map_str():
parsing '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): maps
subst'd pattern: '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): env
subst'd pattern: '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_fixup():
REWRITE_HOME arg now '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrote home to be
'/vhosts/backup/user1'

The home should be set to /vhosts/backup/user1, but in FileZilla I see
content of the /vhosts/backup/.

Did I miss something?

Thanks in advance

Alex Domoradov

2016-02-25 09:31:04 UTC

Permalink

Any suggestions?

Post by Alex Domoradov
Hello,
I'm using the following settings with ProFTPD 1.3.5a
<VirtualHost sftp.example.net>
ServerName "SFTP: Backup server."
DefaultRoot ~
Umask 002
Port 2121
RootRevoke on
AuthUserFile /etc/proftpd/sftp_virtual_users.conf
SFTPEngine on
SFTPLog /var/log/proftpd/sftp.log
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key
SFTPAuthorizedUserKeys file:/etc/proftpd/sftp_users
SFTPCompression delayed
SFTPAuthMethods publickey
SFTPDHParamFile /etc/pki/proftpd/dhparam_2048.pem
RewriteHome on
RewriteEngine on
RewriteLog /var/log/proftpd/rewrite.log
RewriteCondition %m REWRITE_HOME
RewriteRule (.*) /vhosts/backup/%U
</VirtualHost>
The password file contain only one line
# cat /etc/proftpd/sftp_virtual_users.conf
user1:{HASH}:99:99::/vhosts/backup/:/sbin/nologin
according to a log files
2016-02-23 22:32:46,871 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): mod_cap/1.1: adding CAP_SETUID and CAP_SETGID
capabilities
2016-02-23 22:32:46,871 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): SSH2 session opened.
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Preparing to chroot to directory
'/vhosts/backup/user1'
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): USER user1: Login successful
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to seteuid(): Operation
not permitted
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): RootRevoke in effect, dropped root privs
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): USER user1: Login successful.
checking regex cond against 'REWRITE_HOME'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_fixup(): condition
met
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_fixup(): executing
RewriteRule
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): original
pattern: '/vhosts/backup/%U'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): rule
backref subst'd pattern: '/vhosts/backup/%U'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): pattern
'/vhosts/backup/%U' had no cond backrefs
replacing variable '%U' with 'user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): var
subst'd pattern: '/vhosts/backup/user1'
parsing '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): maps
subst'd pattern: '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrite_subst(): env
subst'd pattern: '/vhosts/backup/user1'
REWRITE_HOME arg now '/vhosts/backup/user1'
2016-02-23 22:32:46,950 mod_rewrite/0.9[53242]: rewrote home to be
'/vhosts/backup/user1'
The home should be set to /vhosts/backup/user1, but in FileZilla I see
content of the /vhosts/backup/.
Did I miss something?
Thanks in advance

TJ Saunders

2016-02-26 00:04:17 UTC

Permalink

Post by Alex Domoradov
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Preparing to chroot to directory
'/vhosts/backup/user1'
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
The home should be set to /vhosts/backup/user1, but in FileZilla I see
content of the /vhosts/backup/.

Is it possible that your FTP client (FileZilla) has cached the directory
listing from a previous session, and that is what it is showing you?
I.e. if you close FileZilla, then start it again, do you see the
expected directory contents?

TJ

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
ProFTPD Users List <proftpd-***@proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Alex Domoradov

2016-02-26 00:15:36 UTC

Permalink

oh my god, you were right! It was a cache. Shame on me.

P.S.
but I have found a really fantastic feature of ProFTPD. I can use one
virtual user and do authentications via public key without having to create
additional accounts for users. All I need is to add user public key. And
that's cool.

Thanks for the great ftp server.

Post by TJ Saunders

Is it possible that your FTP client (FileZilla) has cached the directory
listing from a previous session, and that is what it is showing you?
I.e. if you close FileZilla, then start it again, do you see the
expected directory contents?
TJ
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Alex Domoradov

2016-02-26 00:34:18 UTC

Permalink

One more thing.

In my case would be any difference in the rewrite rule between

%u name of authenticated user
%U name of user sent by client via USER

maybe some caveats/pitfalls with %U?

P.S.
I paid attention on the following line

2016-02-23 22:32:46,950 sftp.example.net proftpd[53242] sftp.example.net
(192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to seteuid(): Operation
not permitted

is it normal?

Post by Alex Domoradov
oh my god, you were right! It was a cache. Shame on me.
P.S.
but I have found a really fantastic feature of ProFTPD. I can use one
virtual user and do authentications via public key without having to create
additional accounts for users. All I need is to add user public key. And
that's cool.
Thanks for the great ftp server.

Post by Alex Domoradov

Post by Alex Domoradov
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242]

sftp.example.net

Post by Alex Domoradov
(192.168.1.2[192.168.1.2]): Preparing to chroot to directory
'/vhosts/backup/user1'
2016-02-23 22:32:46,950 sftp.example.net proftpd[53242]

sftp.example.net

Post by Alex Domoradov
(192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
The home should be set to /vhosts/backup/user1, but in FileZilla I see
content of the /vhosts/backup/.

Is it possible that your FTP client (FileZilla) has cached the directory
listing from a previous session, and that is what it is showing you?
I.e. if you close FileZilla, then start it again, do you see the
expected directory contents?
TJ
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

TJ Saunders

2016-02-26 04:05:22 UTC

Permalink

Post by Alex Domoradov
In my case would be any difference in the rewrite rule between
%u name of authenticated user
%U name of user sent by client via USER
maybe some caveats/pitfalls with %U?

Yes, there is a caveat. When using mod_rewrite to rewrite the home
directory, you have to know that it happens _during_ the
authentication process. This means that the USER name that the client
sent (that's the %U variable) has _not_ yet been
authenticated/trusted. Since the %u variable is for the authenticated,
trusted value -- and when the home directory is
being rewritten, it hasn't been trusted yet -- you have to use %U.

Post by Alex Domoradov
I paid attention on the following line
sftp.example.net (192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to seteuid(): Operation not permitted
is it normal?

Yes, that can happen. I would expect that a little earlier in the logs
for that session, you'd see a similar log message
for "ROOT PRIVS: unable to seteuid()"?

TJ

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
ProFTPD Users List <proftpd-***@proftpd.org>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Alex Domoradov

2016-02-26 09:13:16 UTC

Permalink

No, I don't see such message, at least with debug level 5

sftp.example.net (192.168.1.2[192.168.1.2]): Preparing to chroot to
directory '/vhosts/backup/user1'
sftp.example.net (192.168.1.2[192.168.1.2]): Environment successfully
chroot()ed
sftp.example.net (192.168.1.2[192.168.1.2]): in dir_check_full(): path =
'/', fullpath = '/vhosts/backup/user1/'.
sftp.example.net (192.168.1.2[192.168.1.2]): in dir_check_full(): setting
umask to 0002 (was 0022)
sftp.example.net (192.168.1.2[192.168.1.2]): USER user1: Login successful
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_cap
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_delay
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_log
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_ls
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_auth
sftp.example.net (192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to
seteuid(): Operation not permitted
sftp.example.net (192.168.1.2[192.168.1.2]): RootRevoke in effect, dropped
root privs

Post by TJ Saunders

Post by Alex Domoradov
In my case would be any difference in the rewrite rule between
%u name of authenticated user
%U name of user sent by client via USER
maybe some caveats/pitfalls with %U?

Post by Alex Domoradov
I paid attention on the following line
sftp.example.net (192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to

seteuid(): Operation not permitted

Post by Alex Domoradov
is it normal?

Yes, that can happen. I would expect that a little earlier in the logs
for that session, you'd see a similar log message
for "ROOT PRIVS: unable to seteuid()"?
TJ

Alex Domoradov

2016-02-29 10:43:35 UTC

Permalink

BTW. I have found interesting behavior. A file you have specified in the
SFTPAuthorizedUserKeys MUST contain a new line in the end. Otherwise you
will get error

mod_sftp/0.9.9[20427]: line too long (29) on line 13 of
'/etc/proftpd/sftp_authorized_keys'
mod_sftp/0.9.9[20427]: Make sure that '/etc/proftpd/sftp_authorized_keys'
is a RFC4716 formatted key
mod_sftp/0.9.9[20427]: error comparing keys from
'/etc/proftpd/sftp_authorized_keys': Invalid argument
mod_sftp/0.9.9[20427]: sending userauth failure; remaining userauth
methods: publickey
mod_sftp/0.9.9[20427]: client at 192.168.1.2 sent SSH_DISCONNECT message:
No supported authentication methods available (No other authentication
mechanisms available)

It seems that someone already has encountered with such issue -
https://sourceforge.net/p/proftp/mailman/message/30476183/

I think it would be a good if you will add some note into the documentation.

Post by Alex Domoradov
No, I don't see such message, at least with debug level 5
sftp.example.net (192.168.1.2[192.168.1.2]): Preparing to chroot to
directory '/vhosts/backup/user1'
sftp.example.net (192.168.1.2[192.168.1.2]): Environment successfully
chroot()ed
sftp.example.net (192.168.1.2[192.168.1.2]): in dir_check_full(): path =
'/', fullpath = '/vhosts/backup/user1/'.
sftp.example.net (192.168.1.2[192.168.1.2]): in dir_check_full(): setting
umask to 0002 (was 0022)
sftp.example.net (192.168.1.2[192.168.1.2]): USER user1: Login successful
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_cap
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_delay
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_log
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_ls
sftp.example.net (192.168.1.2[192.168.1.2]): dispatching POST_CMD command
'PASS (hidden)' to mod_auth
sftp.example.net (192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to
seteuid(): Operation not permitted
sftp.example.net (192.168.1.2[192.168.1.2]): RootRevoke in effect,
dropped root privs

Post by TJ Saunders

Post by Alex Domoradov
In my case would be any difference in the rewrite rule between
%u name of authenticated user
%U name of user sent by client via USER
maybe some caveats/pitfalls with %U?

Post by Alex Domoradov
I paid attention on the following line
sftp.example.net (192.168.1.2[192.168.1.2]): REVOKE PRIVS: unable to

seteuid(): Operation not permitted

Post by Alex Domoradov
is it normal?

Yes, that can happen. I would expect that a little earlier in the logs
for that session, you'd see a similar log message
for "ROOT PRIVS: unable to seteuid()"?
TJ