[clue-admin] User setup for "member" accounts

[Collins Richey]

On Tue, 4 Jan 2005 12:20:36 -0700, Jed S. Baer <thag at frii.com> wrote:
> On Tue, 4 Jan 2005 11:08:41 -0700
> Collins Richey wrote:
> 
> > Here's the critical question. Do we care whether users can view system
> > directories and other users' directories? Using sftp, there's no way
> > that I have found to execute arbitray commands. I've also been
> > experimenting with seting up a chroot environment, but that's a
> > longterm pain in the butt I would prefer to avoid.
> 
> We can mitigate this quite a bit using umask and making sure file
> permissions are the most restrictive they can be.
> 
> If we make the members' default umasks 0077, then there's no group access
> by default for files created. Only problem is, I don't see how (yet) to do
> that with sftp, since it seems to be something that's associated with
> shells. (But that can't be entirely true.)

I don't have a problem (conceptually) with whether others can see my work.

> 
> Looks like sftp (via sshd) will use the "profile" to get a umask. That
> means /etc/profile or its equivalent for other shells. I infer that ssh
> determines what the user's login shell is (even if it's not being invoked)
> and executes the "non-interactive" initialization file. But with the
> sftp-server as the login shell, I'm not finding anything so far saying
> what, if anything, it reads as an initialization file.
> 
> What I am finding is a hack.
> http://wiki.gnuarch.org/moin.cgi/Centralized_20Development
> 
> The trick is to make an sftp-wrapper file like so:
> 
> [quote]
> #!/bin/sh
> umask 002
> exec /usr/lib/sftp-server $@
> 
> I don't think the $@ is really necessary, since no args are passed to the
> sftp server by sshd, but it seems harmless. I added it mostly out of
> habit, since it's a good idea to pass down arguments using "$@" or
> something similar when you write a wrapper.
> 
> Then you change the line in sshd_config to read:
> 
> Subsystem       sftp    /usr/local/lib/sftp-wrapper
> [/quote]
> 
> Obviously, we'd use a different umask value.
> 
> I'd rather get to the root of controlling the umask without resorting to
> shell trickery. But I'm really striking out using Google to find a
> definitive answer not involving a typical login shell.
> 
> I guess I'll experiment at home here a bit.
> 

I don't have a problem with using a wrapper script.

-- 
 Collins