PermitUserEnvironment

[Daniel Allen]

Daniel Allen wrote on Fri Sep 4 23:46:12 EST 2009:
 >
 > Damien Miller wrote:
 >
 > > We could make PermitUserEnvironment accept a pattern-list to match
 > > environment variables, while retaining "yes", "no", "true" and   
"false"
 > > as their current meanings of allow/deny-all.
 >
 > [...]  The pattern-list would seem the more elegant approach for our
 > use.  I am sorry that I don't have the wherewithal to submit a patch
 > now, though if it helps things along I'd be happy to submit a  
bugzilla
 > request.  Or not, if you prefer.

I'd like to let you know that we're reviewing a patch which does just as
described, to accept a pattern for PermitUserEnvironment. It affects  
vars
defined in $HOME/.ssh/environment and authorized_keys. It only
accepts a single pattern, which is used as a case-insensitive stem for
allowed variables. I will send along the patch as soon as I've had a few
colleagues review it.

While I'm digging: there is a secondary area of interest I'd appreciate
comment on.

If PermitUserEnvironment is turned off, but an "environment=" option is
specified in authorized_keys, the key is rejected and the user sees a
"Bad options in file" error, which cannot be muted.

Versus "permitopen=" option, which sshd silently ignores if
AllowTcpForwarding is turned off.

What do people think about a (short) patch to silently ignore
"environment=" specifications on disabled PermitUserEnvironment?
It seems like a not-too-controvertial thing, especially since sshd  
silently
ignores the same variables if they are in $HOME/.ssh/environment if
PermitUserEnvironment is off.

And it would prevent a FAQish question which I'm sure we'll
see if we start using environment parameters as we expect to...

Thanks,
Daniel Allen
Computing Technology Specialist
Computer Science Computing Facility (CSCF)
David R. Cheriton School of Computer Science
University of Waterloo
(519) 888-4567 ext. 35448
drallen at uwaterloo dot ca