Discussion:
umask in chroot'ed internal-sftp
Rodolfo Gouveia
2012-03-27 12:27:06 UTC
Permalink
Hi all,
Right now I have a chroot'ed internal-sftp for all users
belonging to group chroot, /etc/ssh/sshd_config:
Match Group chroot
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/%u
And I would like to set a different umask for them so I tried
changing the 'ForceCommand...' to:
ForceCommand internal-sftp -u 0007
but didn't work. Also tried addidng a new login class in
/etc/login.conf:
chroot:\
:umask=007
but it seems that internal-sftp doesn't use it.

Any ideas?
Thanks.


Cheers,
rodolfo
Stefan Sieg
2012-03-28 16:33:16 UTC
Permalink
Post by Rodolfo Gouveia
Hi all,
Right now I have a chroot'ed internal-sftp for all users
Match Group chroot
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/%u
And I would like to set a different umask for them so I tried
ForceCommand internal-sftp -u 0007
but didn't work. Also tried addidng a new login class in
chroot:\
:umask=007
but it seems that internal-sftp doesn't use it.
Any ideas?
Thanks.
Cheers,
rodolfo
are you overwriting existing files that have the previous file mode?
Rodolfo Gouveia
2012-03-29 18:37:47 UTC
Permalink
Post by Stefan Sieg
are you overwriting existing files that have the previous file mode?
No, these are new files. Let me explain better.
When I copy a file over with sftp, the permissions of the file created
on the server, are replicated from the client.
This is in contrast, when I'm logged in on the server with that same account
and create a file, the umask is correct as per /etc/login.conf.
Even though reading sftp-server(8):
-u umask
Sets an explicit umask(2) to be applied to newly-created files
and directories, instead of the user's default mask.
I would assume that the files copied over by the client which don't exist
on the server should be honor this flag.
Are my assumptions correct?
Eugene Yunak
2012-03-29 22:08:00 UTC
Permalink
Post by Rodolfo Gouveia
Post by Stefan Sieg
are you overwriting existing files that have the previous file mode?
No, these are new files. Let me explain better.
When I copy a file over with sftp, the permissions of the file created
on the server, are replicated from the client.
This is in contrast, when I'm logged in on the server with that same account
and create a file, the umask is correct as per /etc/login.conf.
-u umask
Sets an explicit umask(2) to be applied to newly-created files
and directories, instead of the user's default mask.
I would assume that the files copied over by the client which don't exist
on the server should be honor this flag.
Are my assumptions correct?
This is because your client *asks* the server to set the specific
permissions.

Regards,
Eugene
--
The best the little guy can do is what
the little guy does right
Stefan Sieg
2012-03-29 20:23:40 UTC
Permalink
Post by Rodolfo Gouveia
Post by Stefan Sieg
are you overwriting existing files that have the previous file mode?
No, these are new files. Let me explain better.
When I copy a file over with sftp, the permissions of the file created
on the server, are replicated from the client.
whithout applying the umask?
Post by Rodolfo Gouveia
This is in contrast, when I'm logged in on the server with that same account
and create a file, the umask is correct as per /etc/login.conf.
-u umask
Sets an explicit umask(2) to be applied to newly-created files
and directories, instead of the user's default mask.
I would assume that the files copied over by the client which don't exist
on the server should be honor this flag.
Are my assumptions correct?
It should, here is what i get ...

# groupadd -g 1500 user
# useradd -u 1500 -g 1500 -d /chroot/user -m user
# chown root.wheel /chroot/user
# mkdir /chroot/user/files
# chown user.user /chroot/user/files
# groupadd -g 2000 chroot
# usermod -G chroot user
# touch /testfile; chmod 777 /testfile

# grep "Match Group chroot" -A6 /etc/ssh/sshd_config
Match Group chroot
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/%u

# sftp ***@localhost
Connected to localhost.
sftp> pwd
Remote working directory: /
sftp> cd files
sftp> put /testfile
sftp> ls -l
-rwxr-xr-x 1 1500 1500 9018334 Mar 29 19:51 testfile

the filemode is what it should be with an umask of 022

--------

with "-u 007" in sshd_config

....

sftp> put /testfile
sftp> ls -l
-rwxrwx--- 1 1500 1500 9018334 Mar 29 19:54 testfile

the filemode is what it should be with an umask of 007

What is different in your setup?
Rodolfo Gouveia
2012-04-03 20:59:31 UTC
Permalink
Post by Stefan Sieg
What is different in your setup?
I was specifying the -u flag to internal-sftp instead of the
sftp-server.

Thanks for you help.

Stefan Sieg
2012-03-29 22:16:11 UTC
Permalink
Post by Rodolfo Gouveia
Hi all,
Right now I have a chroot'ed internal-sftp for all users
Match Group chroot
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/%u
And I would like to set a different umask for them so I tried
ForceCommand internal-sftp -u 0007
but didn't work. Also tried addidng a new login class in
chroot:\
:umask=007
but it seems that internal-sftp doesn't use it.
Any ideas?
Thanks.
Cheers,
rodolfo
What sftp client du you use?
Loading...