openssh unix dev - Mar 2008 - ForceCommand and NFS-shared home directories

> > On Mar 22, 2008, at 3:32 PM, Chris Wilson wrote:
> >
> >> As I understand the "ForceCommand" in the sshd_confing
file is meant to
> >> ignore any command supplied by the client, but if user's home
is shared
> >> by server and client machines over network (ex. NFS) then user can
> >> still put something else into ~/.ssh/rc file and overcome this
> >> limitation. Is it possible to disable execution of the ~/.ssh/rc
file
> >> in such a case?
>
> On Sun, 23 Mar 2008, Jeremy McMillan wrote:
>
> > This problem can be solved by chowning the rc (and user conf files)
> > files to some other user and chmod'ing the group and other write
bits
> > off. I say this because usually, when people use
"ForceCommand" the
> > intention is to severely restrict a particular account. Going down
> > this path requires that you do a lot of homework around restricted
> > shells/profiles/etc. and changes you might need to make to the
> > default environment your OS provides. Ssh cannot and should not be
> > expected to encapsulate all of the things that need attention if this
> > is your goal.
>
Frankly I can't imagine a case where while using "ForceCommand"
the
shell/profile or user environment could be useful. But certanly I could be
mistaken.
What I have in mind here is a CVS/SVN server that uses SSH for
authorization. In this case users should have no shell access to the
server at all.
> Unfortunately I don't believe that you are correct in general.
>
> If the user has read-write access to their home directory, and it's not
> protected by some bizarre magical filesystem, then they can replace .ssh
> at will. For example:
>
> mkdir ~/.ssh2
> echo "echo 'Hello there!'" > ~/.ssh2/rc
> mv ~/.ssh ~/.ssh.old
> mv ~/.ssh2 ~/.ssh
>
> This should be possible, whatever permissions you place on ~/.ssh or its
> contents. If you can see a flaw in my logic then I'd be very interested
to
> hear it.
>
> Mikhail, I don't believe there is an option to disable the rc file at
> present, but it sounds like a useful thing to add.
>
Yes in cases like my this option would be very useful.
Meantime do you think that writing a wrapper script for the shell on the
server that bypasses everything but the predefined in "ForceCommand"
command would be a reasonable workaround?

Regards,
Mikhail

On Mon, 24 Mar 2008, Mikhail Terekhov wrote:
>
> Yes in cases like my this option would be very useful.
> Meantime do you think that writing a wrapper script for the shell on the
> server that bypasses everything but the predefined in
"ForceCommand"
> command would be a reasonable workaround?
>
Since it is sshd and not any shell running the ~/.ssh/rc file.  No amount 
of workarounds will resolve this.  Only change the sshd can change this 
behavior.

Taking a glance (because I don't have time to look at it fully right now) 
the changes are ...

1. add: int is_forcedcommand; to session.h
2. modify line 1206 (or so) to read:

-        /* ignore _PATH_SSH_USER_RC for subsystems */
+	 /* ignore _PATH_SSH_USER_RC for subsystems and forced commands */
-        if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st)
>= 0)) {
+        if (!s->is_subsystem && !s->forcedcommand && 
+	     (stat(_PATH_SSH_USER_RC, &st) >= 0)) {
                 snprintf(cmd, sizeof cmd, "%s -c '%s %s'",
                     shell, _PATH_BSHELL, _PATH_SSH_USER_RC);
4. Maybe initialize s->is_forcedcommand = 0;  (maybe, because we may do a
 	bzero() or other such magic to clear memory for this struct)
3. Find the right place to set s->is_forcedcommand = 1; (Since I've been
 	out of the code for too many years.  I can't state the right
 	place at this moment.  I assume still somewhere in sessions.c)



- Ben