[scponly] scponly and umask
Joshua Ball
sciolizer at gmail.com
Tue Jan 29 15:57:57 EST 2008
Kaleb,
Thanks for the advice. I added the umask line right before the if
statement whose else clause had the execve(...). I've done very little
C, but that seemed like the right place to put it.
Anyway, I think it's a moot point, because I think the umask IS
working, just not the way I want it to. Whether because of the patch
or because of the 4 other things I tried, the mask is working: If I
upload a file whose permissions on my local machine are 777, then they
are changed to 775 on the remote server. But I want more than just a
mask; I want the permissions of newly created files and folders to be
based not on the client or the client's computer's permissions, but
based on a config file (or even a hard-coded value) on the server.
E.g. when I upload a file whose local permissions are 700, I want them
to be 775 on the server.
But I guess the only way to do that is to patch sftp-server. (I also
looked into setfacl, but our file system does not support directory
masks.)
It seems the least hackish solution is the old-fashioned one: training
our customers to do their own chmods. Tech support FTW! :)
Again, thanks for you help.
Josh "Ua" Ball
On Jan 28, 2008 5:41 PM, Kaleb Pederson <kaleb.pederson at gmail.com> wrote:
> Joshua,
>
> This is actually a fairly common problem. To make matters worse, some
> sftp/upload clients will always attempt to set certain permissions while
> others will not.
>
> There is not currently a good solution to this. For my installation, I
> patched scponly to set the umask with the umask function (man 3p umask) after
> the user was chrooted and setuid permissions dropped. I'm not sure if it's
> something that's generally useful though.
>
> The patch is as simple as adding the following line at the right place:
>
> umask(002); /* NOTE: <sys/stat.h> is already included in scponly.c */
>
> I hope that helps.
>
> --Kaleb
>
>
>
> On Monday 28 January 2008, Joshua Ball wrote:
> > UPDATE:
> >
> > I created another PAM chroot where the shell was bash, and it was as
> > immune to my umask attempts as the accounts using scponly. So I guess
> > the problem is with pam chroots, not with scponly. If you still have
> > ideas, then I'll be glad to hear them, but otherwise, my apologies for
> > posting to the wrong list.
> >
> > Josh "Ua" Bal
> >
> > On 1/28/08, Joshua Ball <sciolizer at gmail.com> wrote:
> > > Greetings,
> > >
> > > We have a setup on our server where some of our users use scponly as
> > > their shell, and the scponly binary is kept in a PAM-controlled
> > > chroot. (I am aware that there are security limitations to this, but
> > > the concern is more about simplicity of interface than about security.
> > > It would not be disastrous if our users managed to execute bash.)
> > >
> > > I want the default umask to be 0002. Most importantly, I want uploaded
> > > files and newly created folders to have g+rwx permissions. (It is ok
> > > if the user decides to chmod the files later to something more
> > > restrictive.)
> > >
> > > According to
> > > <https://lists.ccs.neu.edu/pipermail/scponly/2004-June/000556.html>,
> > > this is beyond scponly's control, but I am at my whit's end trying to
> > > figure out how else to change the umask. The things I have tried:
> > >
> > > - Adding "umask 002" to ~/.ssh/rc
> > >
> > > - Adding "umask 002" to /etc/ssh/sshrc
> > >
> > > - Changing the Subsystem sftp line in /etc/ssh/sshd_config to point to
> > > the shell script:
> > > #!/usr/bin/env bash
> > > umask 007
> > > exec /usr/lib/openssh/sftp-server
> > >
> > > - Patching ssh with the sftplogging patch, and adding "Umask 0002" to
> > > /etc/ssh/sshd_config file.
> > >
> > > Some of the techniques work for regular accounts, but none of them
> > > work for the accounts using scponly as their shell.
> > >
> > > Any help would be appreciated.
> > >
> > > Josh "Ua" Ball
> >
> > _______________________________________________
> > scponly mailing list
> > scponly at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/scponly
>
>
>
More information about the scponly
mailing list