Bug 484261

+++ This bug was initially created as a clone of Bug #481233 +++

Description of problem:

We have cifs mounted home directories on an RHEL5.3 client from an RHEL4 or RHEL5 samba server and are seeing incorrect file permissions via ssh.  This breaks the security checks performed by ssh on the authorized_keys file.


Version-Release number of selected component (if applicable):

Client running kernel 2.6.18-128.el5
Server running rhel4 or rhel5


How reproducible:

always


Steps to Reproduce:
1. Mount your home directory via cifs from an RHEL samba server with unix extensions enabled.

2. Set permissions on ~/.ssh/authorized_keys to various values

3. Try to ssh with your keys loaded
  
Actual results:

It fails with:

  Authentication refused: bad ownership or modes for file /home/username/.ssh/authorized_keys

with any permission on the authorized_keys file that includes the owner write bit (such as 600).

It *works* with any permissions on the authorized_keys file that doesn't include the owner write bit, including obviously bad values like 466 and 477.


Expected results:

It should refuse to use the authorized_keys file if group or world writable but accept it otherwise.


Additional info:

This problem shows up with authorized_keys permissions but is a general problem of permissions being interpreted improperly.  For example, I'm logged into a system named 'test' and see the following when I ssh back to this machine:

% chmod 466 .ssh/authorized_keys
% ls -l .ssh/authorized_keys
-r--rw-rw- 1 robh staff 677 Sep 18 16:02 .ssh/authorized_keys
% ssh test ls -l .ssh/authorized_keys
-r-xr-Sr-x 1 robh staff 677 Sep 18 16:02 .ssh/authorized_keys
% ssh test ls -l .ssh |grep authorized_keys
-r--rw-rw- 1 robh staff  677 Sep 18 16:02 authorized_keys
% chmod 600 .ssh/authorized_keys
% ssh test ls -l .ssh/authorized_keys
robh@test's password: 
-rw------- 1 robh staff 677 Sep 18 16:02 .ssh/authorized_keys
% ssh test ls -l .ssh | grep authorized_keys
robh@test's password: 
-rw------- 1 robh staff  677 Sep 18 16:02 authorized_keys
% 

Note that the ssh with permissions set to 466 didn't prompt for a password (I have my key loaded) but it did prompt for a password with valid permissions of 600.

--- Additional comment from rwheeler on 2009-01-23 07:45:10 EDT ---

Jeff, sounds like this is one for you to look at?

--- Additional comment from jlayton on 2009-01-23 10:36:22 EDT ---

Ok, I was able to reproduce this on RHEL5 but not on rawhide. Looks like we're getting a different mode in the lstat call:

3002  lstat("/home/testuser/.ssh/authorized_keys", {st_dev=makedev(0, 24), st_ino=9484, st_mode=S_IFREG|S_ISGID|0767, st_nlink=1, st_uid=50
000, st_gid=50000, st_blksize=16384, st_blocks=8, st_size=413, st_atime=2009/01/23-08:29:14, st_mtime=2009/01/23-08:29:14, st_ctime=2009/01
/23-08:29:14}) = 0

...that st_mode typically the mode we see when unix extensions are disabled.

--- Additional comment from jlayton on 2009-01-23 10:59:54 EDT ---

Actually, it's even stranger:

3002  stat("/home/testuser/.ssh/authorized_keys", {st_dev=makedev(0, 24), st_ino=9484, st_mode=S_IFREG|0644, st_nlink=1, st_uid=50000, st_g
id=50000, st_blksize=16384, st_blocks=8, st_size=413, st_atime=2009/01/23-08:29:14, st_mtime=2009/01/23-08:29:14, st_ctime=2009/01/23-08:30
:19}) = 0
3002  open("/home/testuser/.ssh/authorized_keys", O_RDONLY) = 4
...
3002  lstat("/home/testuser/.ssh/authorized_keys", {st_dev=makedev(0, 24), st_ino=9484, st_mode=S_IFREG|S_ISGID|0767, st_nlink=1, st_uid=50
000, st_gid=50000, st_blksize=16384, st_blocks=8, st_size=413, st_atime=2009/01/23-08:29:14, st_mtime=2009/01/23-08:29:14, st_ctime=2009/01
/23-08:29:14}) = 0

...I may be able to roll up a reproducer from that.

--- Additional comment from jlayton on 2009-01-23 11:11:45 EDT ---

Created an attachment (id=329849)
reproducer program

Looks like this can reproduce it. We stat the file, then open it and lstat it. The mode on the lstat is wrong.

# ./reproducer /home/testuser/.ssh/authorized_keys
mode1 = 100644
mode2 = 102767

--- Additional comment from jlayton on 2009-01-23 11:13:37 EDT ---

On rawhide the results of the reproducer are correct:

mode1 = 100644
mode2 = 100644

--- Additional comment from robh.edu on 2009-01-23 12:03:34 EDT ---

You might want to try it on rawhide with a mode other than 644 (like 477).  I am seeing cases where 644 doesn't expose the bug but other modes do.  For example:

Case 1:  2.6.18-92.1.22.el5 kernel with file mode 644

mode1 = 100644
mode2 = 100644

Case 2:  2.6.18-92.1.22.el5 kernel with file mode 477

mode1 = 100477
mode2 = 100455

Case 3:  2.6.18-128.el5 kernel with file mode 644

mode1 = 100644
mode2 = 102767

Case 4:  2.6.18-128.el5 kernel with file mode 477

mode1 = 100477
mode2 = 102545


So, both RHEL 5.2 and 5.3 kernels have problems but they are behaving differently.

--- Additional comment from jlayton on 2009-01-23 12:21:27 EDT ---

What's happening is that we're falling into non-unix extension codepaths incorrectly.

The 5.3 kernels have some patches to give files sane modes when unix extensions aren't enabled. When you set the mode to 0477, then samba is setting the ATTR_READONLY bit when you do a QueryPathInfo call.

The default file mode for cifs is 02767. When the ATTR_READONLY bit is set, we clear all the write bits from the mode, so you end up with 02545.

I see the bug and have a patch that I'll attach in a few mins.

--- Additional comment from jlayton on 2009-01-23 12:23:43 EDT ---

Created an attachment (id=329857)
patch -- add missing else statement in cifs_open_inode_helper

This patch should fix it. The problem was a missing else statement in cifs_open_inode_helper(). I'll plan to add this to my test kernels for now and will propose it as part of the CIFS update for 5.4.

--- Additional comment from jlayton on 2009-01-28 14:53:06 EDT ---

I've added this patch to the test kernels on my people.redhat.com page:

http://people.redhat.com/jlayton

...if you're able to test them somewhere non-critical then please do and report back whether this fixes the problem for you.

--- Additional comment from robh.edu on 2009-01-28 15:48:32 EDT ---

I applied your patch to the stock rhel5.3 2.6.18-128 kernel and it resolved this problem in all of my testing.  I also grabbed your jtltest.60 kernel and that one also seems to have resolved this problem.  Thanks!