Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-27 Thread Grant Coady
On Wed, 17 Jan 2007 22:55:19 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hello Santiago,
>
>On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
>> Hi!
>> 
>> I have discovered a problem with the changes applied to smbfs in 2.4.34 and
>> in the security backports like last Debian's 2.4 kernel update these changes
>> seem to be made to solve CVE-2006-5871 and they have broken symbolic links
>> and changed the way that special files (like devices) are seen.
>> 
>> For example:
>> Before: symbolic links were seen as that, symbolic links an thus if you tried
>> to open the file the link was followed and you ended up reading the
>> destination file
>> Now: symbolic links are seen as normal files (at least with a ls) but their
>> length (N) is the length of the symbolic link, if you read it, you'll get the
>> first N characters of the destination file. For example, on my filesystem
>> bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
>> get ELF (this is, the first 4 characters of the bash program, first one
>> being a DEL).
>> 
>> Another example:
>> Before: if you did a ls of a device file, like dev/zero you could see it as
>> a device, if you tried opening it, it wouldn't work, but if you did a cp -a
>> of that file to a local filesystem the result was a working zero device.
>> Now: the devices are seen as normal files with a length of 0 bytes.
>> 
>> Seems to me like a mask is erasing some mode bits that shouldn't be erased.
>> 
>> I have carried my tests on a Debian Sarge machine always mounting the share
>> using: smbmount //server/share /mnt without any other options. The tests
>> were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
>> Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
>> samba 3.0.23d and I have experienced the same behaviour with samba's
>> unix extensions = yes and unix extensions = no.
>> 
>> I don't know what else to add, if you need any more info or want me to do
>> any tests just ask for it.
>
>Well, there is not much to add there. Thanks very much for all your tests.
>This problem was not easy to fix, and Dann Frazier did a careful job at
>backporting it and testing it. Unfortunately, corner cases like this may
>sometimes pass through the tests.
>
>Dann, do you still have your samba server ready to try to reproduce this
>problem ? Also, there are very suspect lines right there in the patch :
>
>@@ -505,8 +510,13 @@
>   mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
>   mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> 
>-  mnt->flags = (oldmnt->file_mode >> 9);
>+  mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
>+  SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
>+  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG;
>+  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
>
>
>See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
>expected thing like this but I wonder if the initial intent was exactly this.
>Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
>what I say is stupid, but it's just a guess.
>
>Santiago, if you feel brave enough to try completely untested code, I
>would suggest to try this change :
>
>   } else {
>-  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFREG;
>-  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFDIR;
>+  mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
>+  mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;

I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
to directories seen as target, nor can they be created (Operation not 
permitted...)

(copied /usr to spare partition on server)

Grant.

Results:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 1536
lrwxrwxrwx 1 grant wheel  5 2007-01-18 10:08 X11 -> X11R6/
drwxr-xr-x 1 grant wheel  0 2002-02-22 11:45 X11R6/
lrwxrwxrwx 1 grant wheel  8 2007-01-18 10:08 adm -> /var/adm/
drwxr-xr-x 1 grant wheel  0 2006-12-05 09:06 bin/
drwxr-xr-x 1 grant wheel  0 1993-11-26 14:40 dict/
drwxr-xr-x 1 grant wheel  0 2006-12-01 09:00 doc/
drwxr-xr-x 1 grant 

Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-27 Thread Grant Coady
On Wed, 17 Jan 2007 22:55:19 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hello Santiago,

On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
 Hi!
 
 I have discovered a problem with the changes applied to smbfs in 2.4.34 and
 in the security backports like last Debian's 2.4 kernel update these changes
 seem to be made to solve CVE-2006-5871 and they have broken symbolic links
 and changed the way that special files (like devices) are seen.
 
 For example:
 Before: symbolic links were seen as that, symbolic links an thus if you tried
 to open the file the link was followed and you ended up reading the
 destination file
 Now: symbolic links are seen as normal files (at least with a ls) but their
 length (N) is the length of the symbolic link, if you read it, you'll get the
 first N characters of the destination file. For example, on my filesystem
 bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
 get ELF (this is, the first 4 characters of the bash program, first one
 being a DEL).
 
 Another example:
 Before: if you did a ls of a device file, like dev/zero you could see it as
 a device, if you tried opening it, it wouldn't work, but if you did a cp -a
 of that file to a local filesystem the result was a working zero device.
 Now: the devices are seen as normal files with a length of 0 bytes.
 
 Seems to me like a mask is erasing some mode bits that shouldn't be erased.
 
 I have carried my tests on a Debian Sarge machine always mounting the share
 using: smbmount //server/share /mnt without any other options. The tests
 were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
 Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
 samba 3.0.23d and I have experienced the same behaviour with samba's
 unix extensions = yes and unix extensions = no.
 
 I don't know what else to add, if you need any more info or want me to do
 any tests just ask for it.

Well, there is not much to add there. Thanks very much for all your tests.
This problem was not easy to fix, and Dann Frazier did a careful job at
backporting it and testing it. Unfortunately, corner cases like this may
sometimes pass through the tests.

Dann, do you still have your samba server ready to try to reproduce this
problem ? Also, there are very suspect lines right there in the patch :

@@ -505,8 +510,13 @@
   mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
   mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
 
-  mnt-flags = (oldmnt-file_mode  9);
+  mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
+  SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
+  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG;
+  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }


See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
expected thing like this but I wonder if the initial intent was exactly this.
Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
what I say is stupid, but it's just a guess.

Santiago, if you feel brave enough to try completely untested code, I
would suggest to try this change :

   } else {
-  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFREG;
-  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFDIR;
+  mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
+  mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;

I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
to directories seen as target, nor can they be created (Operation not 
permitted...)

(copied /usr to spare partition on server)

Grant.

Results:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 1536
lrwxrwxrwx 1 grant wheel  5 2007-01-18 10:08 X11 - X11R6/
drwxr-xr-x 1 grant wheel  0 2002-02-22 11:45 X11R6/
lrwxrwxrwx 1 grant wheel  8 2007-01-18 10:08 adm - /var/adm/
drwxr-xr-x 1 grant wheel  0 2006-12-05 09:06 bin/
drwxr-xr-x 1 grant wheel  0 1993-11-26 14:40 dict/
drwxr-xr-x 1 grant wheel  0 2006-12-01 09:00 doc/
drwxr-xr-x 1 grant wheel  0 2006-08-17 16:01 etc/
drwxr-xr-x 1 grant wheel  0 2006-09-09 10:51 games/
drwxr-xr-x 1 grant wheel  0 2005-04-22 05:45 

Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Wed, Jan 24, 2007 at 10:46:24AM +1100, Grant Coady wrote:
> On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> 
> >Users have reported a symlink issue with my recent smbfs backport.
> >Turns out my backport overlooked a second 2.6 patch w/ the fix:
> > http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
> >
> >This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
> >issue, and also cleans up an unnecessary double assignment. As his
> >commit message notes, you will need the userspace patches from Samba
> >Bug #999 in order to use the permission/ownership assigned by the
> >server.
> 
> Server-side:
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 8
> drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
> for comparison:
> 
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.33.3
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 4096
> drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 10
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.4.34c
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 4096
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Great, that's what I'd expect. If you patch your userspace, you can
avoid the executable bits.


-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Grant Coady
On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>Users have reported a symlink issue with my recent smbfs backport.
>Turns out my backport overlooked a second 2.6 patch w/ the fix:
> http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
>
>This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
>issue, and also cleans up an unnecessary double assignment. As his
>commit message notes, you will need the userspace patches from Samba
>Bug #999 in order to use the permission/ownership assigned by the
>server.

Server-side:
[EMAIL PROTECTED]:/home/other$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:/home/other$ ls -l
total 8
drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
for comparison:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

[EMAIL PROTECTED]:~$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 10
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

[EMAIL PROTECTED]:~$ uname -r
2.4.34c
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Grant.

>
>Signed-off-by: dann frazier <[EMAIL PROTECTED]>
>
>diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
>index be975fe..7fd9b51 100644
>--- a/fs/smbfs/inode.c
>+++ b/fs/smbfs/inode.c
>@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
>int silent)
>   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
>   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
>-  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFREG;
>-  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFDIR;
>+  mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG;
>+  mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
>diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
>index 7f0794c..5570007 100644
>--- a/fs/smbfs/proc.c
>+++ b/fs/smbfs/proc.c
>@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
>struct smb_sb_info *server,
> 
>   if ( (server->mnt->flags & SMB_MOUNT_DMODE) &&
>(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFDIR;
>+  fattr->f_mode = (server->mnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFREG;
>+  fattr->f_mode = (server->mnt->file_mode & S_IRWXUGO) |
>+  (fattr->f_mode & S_IFMT);
> 
> }
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Willy Tarreau
On Tue, Jan 23, 2007 at 02:12:57PM -0700, dann frazier wrote:
> Users have reported a symlink issue with my recent smbfs backport.
> Turns out my backport overlooked a second 2.6 patch w/ the fix:
>  
> http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

Perfect. Patch queued.
Thanks for your investigatinos, Dann.

Cheers,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Wed, Jan 24, 2007 at 08:04:36AM +1100, Grant Coady wrote:
> Hi Dann,
> I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
> package with two tiny unrelated (?) patches:

Thanks again Grant. You might check out the patch I just submitted -
turns out this was an issue that was already fixed in 2.6, and that
fix is more complete than my previous one. You'll need the additional
userspace patches to use the server-provided perms (i.e., get rid of
the +x bits).

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 
http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Signed-off-by: dann frazier <[EMAIL PROTECTED]>

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
-   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
if ( (server->mnt->flags & SMB_MOUNT_DMODE) &&
 (S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+   fattr->f_mode = (server->mnt->dir_mode & S_IRWXUGO) | S_IFDIR;
else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
  !(S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr->f_mode = (server->mnt->file_mode & S_IRWXUGO) |
+   (fattr->f_mode & S_IFMT);
 
 }
 


-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Grant Coady
On Tue, 23 Jan 2007 13:19:37 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
>> Hi Grant !
>> 
>> On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
>> > On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
>> > 
>> > >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>> > >Ah, think I see the problem now:
>> > >
>> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 
>> > >17:53:57.247695476 -0700
>> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
>> > >-0700
>> > >@@ -1997,7 +1997,7 @@
>> > >  fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>> > > S_IRWXO)) | S_IFDIR;
>> > >  else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
>> > >!(S_ISDIR(fattr->f_mode)) )
>> > >- fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> > >S_IRWXO)) | S_IFREG;
>> > >+ fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> > >S_IRWXO)) | (fattr->f_mode & S_IFMT);
>> > > 
>> > > }
>> > > 
>> > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
>> > eliminate it from the problem space (hopefully ;) :
>> > [EMAIL PROTECTED]:/home/other$ uname -r
>> > 2.4.34b
>> > [EMAIL PROTECTED]:/home/other$ ls -l
>> > total 9
>> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
>> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
>> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
>> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
>> 
>> It seems to me that there is a difference, because filelink now appears the
>> same size as file. It's just as if we had hard links instead of symlinks.
>
>I was running into this yesterday - turns out that Debian's current
>smbfs package contains a patch that checks for user passed options,
>and disables unix capabilities in that case. It was added in
>3.0.14a-4. I've filed a bug requesting the removal of this patch:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033
>
>Grant: Do you know if are you running a version of smbfs w/ this
>   patch?

Hi Dann,
I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
package with two tiny unrelated (?) patches:

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ find . -name samba*
./n/samba
./n/samba/samba.cups.diff.gz
./n/samba/samba.ssl.diff.gz
./n/samba/samba.SlackBuild
./n/samba/samba-3.0.23c.tar.asc
./n/samba/samba-3.0.23c.tar.bz2
[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zless 
n/samba/samba.cups.diff.gz
--- ./source/configure.orig 2002-10-23 18:06:43.0 -0700
+++ ./source/configure  2002-10-23 18:07:12.0 -0700
@@ -3789,7 +3789,7 @@

CFLAGS="$CFLAGS `$CUPS_CONFIG --cflags`"
LDFLAGS="$LDFLAGS `$CUPS_CONFIG --ldflags`"
-   LIBS="$LIBS `$CUPS_CONFIG --libs`"
+   LIBS="-lcrypt $LIBS `$CUPS_CONFIG --libs`"
 fi
 fi

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zcat 
n/samba/samba.ssl.diff.gz
--- ./source/configure.orig 2002-10-09 13:27:21.0 -0700
+++ ./source/configure  2002-10-23 18:06:43.0 -0700
@@ -12479,7 +12479,7 @@

 fi

-LIBS="-lssl -lcrypto $LIBS"
+LIBS="$LIBS -lssl -lcrypto"

 #if test ! -d ${withval}; then
 #  echo "configure: error: called with --with-ssl, but ssl base directory 
${withval} does not exist or is not a directory. Aborting config" 1>&2

Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
> Hi Grant !
> 
> On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
> > On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> > 
> > >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> > >Ah, think I see the problem now:
> > >
> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
> > >17:53:57.247695476 -0700
> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
> > >-0700
> > >@@ -1997,7 +1997,7 @@
> > >   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> > > S_IRWXO)) | S_IFDIR;
> > >   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> > > !(S_ISDIR(fattr->f_mode)) )
> > >-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | S_IFREG;
> > >+  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > > 
> > > }
> > > 
> > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
> > eliminate it from the problem space (hopefully ;) :
> > [EMAIL PROTECTED]:/home/other$ uname -r
> > 2.4.34b
> > [EMAIL PROTECTED]:/home/other$ ls -l
> > total 9
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
> 
> It seems to me that there is a difference, because filelink now appears the
> same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
 Hi Grant !
 
 On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
  On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
  
  On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
  Ah, think I see the problem now:
  
  --- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
  17:53:57.247695476 -0700
  +++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
  -0700
  @@ -1997,7 +1997,7 @@
 fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
   S_IRWXO)) | S_IFDIR;
 else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
   !(S_ISDIR(fattr-f_mode)) )
  -  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFREG;
  +  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | (fattr-f_mode  S_IFMT);
   
   }
   
  client running 2.4.34 with above patch, server is running 2.6.19.2 to 
  eliminate it from the problem space (hopefully ;) :
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ ls -l
  total 9
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
 
 It seems to me that there is a difference, because filelink now appears the
 same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Grant Coady
On Tue, 23 Jan 2007 13:19:37 -0700, dann frazier [EMAIL PROTECTED] wrote:

On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
 Hi Grant !
 
 On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
  On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
  
  On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
  Ah, think I see the problem now:
  
  --- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 
  17:53:57.247695476 -0700
  +++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
  -0700
  @@ -1997,7 +1997,7 @@
fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
   S_IRWXO)) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
  - fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFREG;
  + fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | (fattr-f_mode  S_IFMT);
   
   }
   
  client running 2.4.34 with above patch, server is running 2.6.19.2 to 
  eliminate it from the problem space (hopefully ;) :
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ ls -l
  total 9
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
 
 It seems to me that there is a difference, because filelink now appears the
 same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

Hi Dann,
I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
package with two tiny unrelated (?) patches:

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ find . -name samba*
./n/samba
./n/samba/samba.cups.diff.gz
./n/samba/samba.ssl.diff.gz
./n/samba/samba.SlackBuild
./n/samba/samba-3.0.23c.tar.asc
./n/samba/samba-3.0.23c.tar.bz2
[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zless 
n/samba/samba.cups.diff.gz
--- ./source/configure.orig 2002-10-23 18:06:43.0 -0700
+++ ./source/configure  2002-10-23 18:07:12.0 -0700
@@ -3789,7 +3789,7 @@

CFLAGS=$CFLAGS `$CUPS_CONFIG --cflags`
LDFLAGS=$LDFLAGS `$CUPS_CONFIG --ldflags`
-   LIBS=$LIBS `$CUPS_CONFIG --libs`
+   LIBS=-lcrypt $LIBS `$CUPS_CONFIG --libs`
 fi
 fi

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zcat 
n/samba/samba.ssl.diff.gz
--- ./source/configure.orig 2002-10-09 13:27:21.0 -0700
+++ ./source/configure  2002-10-23 18:06:43.0 -0700
@@ -12479,7 +12479,7 @@

 fi

-LIBS=-lssl -lcrypto $LIBS
+LIBS=$LIBS -lssl -lcrypto

 #if test ! -d ${withval}; then
 #  echo configure: error: called with --with-ssl, but ssl base directory 
${withval} does not exist or is not a directory. Aborting config 12

Grant.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 
http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
-   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
if ( (server-mnt-flags  SMB_MOUNT_DMODE) 
 (S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+   fattr-f_mode = (server-mnt-dir_mode  S_IRWXUGO) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr-f_mode = (server-mnt-file_mode  S_IRWXUGO) |
+   (fattr-f_mode  S_IFMT);
 
 }
 


-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Wed, Jan 24, 2007 at 08:04:36AM +1100, Grant Coady wrote:
 Hi Dann,
 I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
 package with two tiny unrelated (?) patches:

Thanks again Grant. You might check out the patch I just submitted -
turns out this was an issue that was already fixed in 2.6, and that
fix is more complete than my previous one. You'll need the additional
userspace patches to use the server-provided perms (i.e., get rid of
the +x bits).

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Willy Tarreau
On Tue, Jan 23, 2007 at 02:12:57PM -0700, dann frazier wrote:
 Users have reported a symlink issue with my recent smbfs backport.
 Turns out my backport overlooked a second 2.6 patch w/ the fix:
  
 http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

Perfect. Patch queued.
Thanks for your investigatinos, Dann.

Cheers,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread Grant Coady
On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier [EMAIL PROTECTED] wrote:

Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Server-side:
[EMAIL PROTECTED]:/home/other$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:/home/other$ ls -l
total 8
drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test

Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
for comparison:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test

[EMAIL PROTECTED]:~$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 10
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

[EMAIL PROTECTED]:~$ uname -r
2.4.34c
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

Grant.


Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
-  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFREG;
-  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFDIR;
+  mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG;
+  mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
   if ( (server-mnt-flags  SMB_MOUNT_DMODE) 
(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+  fattr-f_mode = (server-mnt-dir_mode  S_IRWXUGO) | S_IFDIR;
   else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
 !(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+  fattr-f_mode = (server-mnt-file_mode  S_IRWXUGO) |
+  (fattr-f_mode  S_IFMT);
 
 }
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-23 Thread dann frazier
On Wed, Jan 24, 2007 at 10:46:24AM +1100, Grant Coady wrote:
 On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier [EMAIL PROTECTED] wrote:
 
 Users have reported a symlink issue with my recent smbfs backport.
 Turns out my backport overlooked a second 2.6 patch w/ the fix:
  http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
 
 This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
 issue, and also cleans up an unnecessary double assignment. As his
 commit message notes, you will need the userspace patches from Samba
 Bug #999 in order to use the permission/ownership assigned by the
 server.
 
 Server-side:
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.6.19.2a
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 8
 drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
 lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
 -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
 lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
 -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
 lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test
 
 Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
 for comparison:
 
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.33.3
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 4096
 drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
 lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
 -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
 lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
 -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
 lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test
 
 [EMAIL PROTECTED]:~$ uname -r
 2.6.19.2a
 [EMAIL PROTECTED]:~$ ls -l /home/other/
 total 10
 drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
 lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
 lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
 -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
 lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*
 
 [EMAIL PROTECTED]:~$ uname -r
 2.4.34c
 [EMAIL PROTECTED]:~$ ls -l /home/other/
 total 4096
 drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
 lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
 lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
 -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
 lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

Great, that's what I'd expect. If you patch your userspace, you can
avoid the executable bits.


-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Willy Tarreau
Hi Dann,

On Mon, Jan 22, 2007 at 11:19:43AM -0700, dann frazier wrote:
> On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
> > On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED]:/home/other$ uname -r
> > 2.4.34b
> > [EMAIL PROTECTED]:/home/other$ mkdir test
> > [EMAIL PROTECTED]:/home/other$ ln -s test testlink
> > ln: creating symbolic link `testlink' to `test': Operation not permitted
> > [EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file
> > [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
> > ln: creating symbolic link `test2' to `test/file': Operation not permitted
> > 
> > trying to create symlinks.
> > 
> > No problems creating symlinks with 2.4.33.3.
> 
> Yes, I've found that this varies depending upon the options passed. If
> uid=0, I can create symlinks, otherwise I always get permission
> denied. This behavior appears to be consistent with 2.6.
> 
> I also need to do some testing with the proposed patch to smbmount
> that will let you omit options (current versions will always pass an
> option to the kernel, even if you the user did not provide one).
> If you do not pass options, the behavior should fallback to
> server-provided values.
> 
> Note that this bug has been my only interaction with smbfs, so I'm
> certainly no expert on how it *should* behave. My plan is to
> take all of the use cases we're coming up with and try to maintain
> the "historic" 2.4 behavior as much as possible, but still not
> silently dropping user-provided mount options. When the behavior needs
> to change to honor them, I'll try to match what current 2.6
> does. Make sense?

Yes, it does for me. So to sum up, I apply your patch to 2.4.34.1
and it restores the same behaviour for Santiago and Grant as they get
in 2.6. Whether it's the expected behaviour or not is not the point,
as it will be easier for us to later mimic 2.6 if a change is needed
since we're not experts at all in this area.

If we're all OK for this, I'll go with that.

Thanks guys,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread dann frazier
On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
> On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.34b
> [EMAIL PROTECTED]:/home/other$ mkdir test
> [EMAIL PROTECTED]:/home/other$ ln -s test testlink
> ln: creating symbolic link `testlink' to `test': Operation not permitted
> [EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file
> [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
> ln: creating symbolic link `test2' to `test/file': Operation not permitted
> 
> trying to create symlinks.
> 
> No problems creating symlinks with 2.4.33.3.

Yes, I've found that this varies depending upon the options passed. If
uid=0, I can create symlinks, otherwise I always get permission
denied. This behavior appears to be consistent with 2.6.

I also need to do some testing with the proposed patch to smbmount
that will let you omit options (current versions will always pass an
option to the kernel, even if you the user did not provide one).
If you do not pass options, the behavior should fallback to
server-provided values.

Note that this bug has been my only interaction with smbfs, so I'm
certainly no expert on how it *should* behave. My plan is to
take all of the use cases we're coming up with and try to maintain
the "historic" 2.4 behavior as much as possible, but still not
silently dropping user-provided mount options. When the behavior needs
to change to honor them, I'll try to match what current 2.6
does. Make sense?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Grant Coady
On Mon, 22 Jan 2007 10:36:30 +0100, Santiago Garcia Mantinan <[EMAIL 
PROTECTED]> wrote:

>> > As you can see I now can see the symbolic links perfectly and they work as
>> > expected.
>> > 
>> > In fact, this patch is working so well that it poses a security risk, as 
>> > now
>> > the devices on my /mnt/dev directory are not only seen as devices (like 
>> > they
>> > were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
>> 
>> Why do you consider this a security problem ? Is any user able to create a
>> device entry with enough permissions ? As a general rule of thumb, networked
>> file systems should be mounted with the "nodev" option.
>
>You are completely right on that, it is just that I thought those devices
>didn't work on 2.4.33, but I just retested again and they work ok, only that
>they were not working to me on the PC I tested the other day and it was
>because of a nodev option :-) just that.
>
>So... I have finised with my tests, I have tested an x86 client on which it
>worked ok, just like on the PowerPC client, both working perfectly just like
>they used to do on 2.4.33.
>
>> Grant, just to be sure, are you really certain that you tried the fixed 
>> kernel ?
>> It is possible that you booted a wrong kernel during one of your tests. I'm
>> intrigued by the fact that it changed nothing for you and that it fixed the
>> problem for Santiago.
>
>Maybe he had also applied some of the earlier patches you had sent and that
>I did not apply to mine?
>
>Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
>I'm running a pristine kernel with just this latest patch applied, the one
>that changes S_IFREG for (fattr->f_mode & S_IFMT).

Same kernel + patch here for latest results posting :)  We seem to get 
similar results now -- though I query the file execute bits coming up.

Grant.
>
>Regards...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Grant Coady
On Mon, 22 Jan 2007 10:18:16 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Grant, just to be sure, are you really certain that you tried the fixed kernel 
>?
>It is possible that you booted a wrong kernel during one of your tests. I'm
>intrigued by the fact that it changed nothing for you and that it fixed the
>problem for Santiago.

Closest I get to Santiago's results are with the 2.4.33.7 plus the patch, 
with 'use default NLS' option turned on, as well as the unix extensions.

2.4.34 was a no go for me.  Changing the default NLS made no difference, 
now trying with unix extensions turned on. . .  Yeah, that works, apart 
from the test file gaining execute bits, compared to operation under 
2.4.33.3, this is 2.4.34 + patch + default NLS and unix extensions:

[EMAIL PROTECTED]:/home/other$ cat dirlink/filelink
this is a test
[EMAIL PROTECTED]:/home/other$ echo "this is a test" > testfile
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
drwxr-xr-x 1 grant wheel  0 2007-01-22 10:45 test/
-rwxr-xr-x 1 grant wheel 15 2007-01-22 21:31 testfile*
lrwxr-xr-x 1 grant wheel  4 2007-01-22 21:29 testlink -> test/
[EMAIL PROTECTED]:/home/other$ ln -s testfile testfilelink
[EMAIL PROTECTED]:/home/other$ cat testfilelink
this is a test


The fix depends on the smbfs configuration?  Is this the requirement?
I ask as the other mode of operation (unix extensions turned off): do 
not display symlinks, prevent creation of symlinks, seems to be logically 
self-consistent, as well as matching what I see from a 'doze box.

Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Santiago Garcia Mantinan
> > As you can see I now can see the symbolic links perfectly and they work as
> > expected.
> > 
> > In fact, this patch is working so well that it poses a security risk, as now
> > the devices on my /mnt/dev directory are not only seen as devices (like they
> > were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
> 
> Why do you consider this a security problem ? Is any user able to create a
> device entry with enough permissions ? As a general rule of thumb, networked
> file systems should be mounted with the "nodev" option.

You are completely right on that, it is just that I thought those devices
didn't work on 2.4.33, but I just retested again and they work ok, only that
they were not working to me on the PC I tested the other day and it was
because of a nodev option :-) just that.

So... I have finised with my tests, I have tested an x86 client on which it
worked ok, just like on the PowerPC client, both working perfectly just like
they used to do on 2.4.33.

> Grant, just to be sure, are you really certain that you tried the fixed 
> kernel ?
> It is possible that you booted a wrong kernel during one of your tests. I'm
> intrigued by the fact that it changed nothing for you and that it fixed the
> problem for Santiago.

Maybe he had also applied some of the earlier patches you had sent and that
I did not apply to mine?

Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
I'm running a pristine kernel with just this latest patch applied, the one
that changes S_IFREG for (fattr->f_mode & S_IFMT).

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Willy Tarreau
Hi Santiago !

On Mon, Jan 22, 2007 at 09:54:00AM +0100, Santiago Garcia Mantinan wrote:
> Hi again!
> 
> I tried to replicate the problem at home during the weekend with my laptop,
> but I couldn't get it to show links with previous kernels, so I guess I had
> something different on my samba server or similar, I'm at the real machines
> now so I have done the real tests and they look promising. I'm getting
> completely different results than those of Grant, which seems really weird.
> 
> I applied just this patch:
> 
> > > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c2007-01-19 
> > > >17:53:57.247695476 -0700
> > > >+++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 
> > > >-0700
> > > >@@ -1997,7 +1997,7 @@
> > > > fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | 
> > > > S_IRWXG | S_IRWXO)) | S_IFDIR;
> > > > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> > > >   !(S_ISDIR(fattr->f_mode)) )
> > > >-fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | 
> > > >S_IRWXG | S_IRWXO)) | S_IFREG;
> > > >+fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | 
> > > >S_IRWXG | S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > > > 
> > > > }
> 
> To an unpatched 2.4.34, the client is an IBM NetworkStation 1000 (a PowerPC
> based thin client), and the server is a normal amd64 based PC running
> 2.6.19.1, both running Debian, the client runs Sarge and the Server Etch.
> I'm descriving this to see if differences on the architectures could be
> causing the differences on behaviour between my tests and Grant's.
> 
> > > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
> > > eliminate it from the problem space (hopefully ;) :
> > > [EMAIL PROTECTED]:/home/other$ uname -r
> > > 2.4.34b
> > > [EMAIL PROTECTED]:/home/other$ ls -l
> > > total 9
> > > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> > > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> > > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
> > > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
> > 
> > It seems to me that there is a difference, because filelink now appears the
> > same size as file. It's just as if we had hard links instead of symlinks.
> 
> Here is what I did, I mounted the remote filesystem on /mnt on my client,
> the share on the server has a normal Debian Sarge PowerPC filesystem on it.
> 
> $ pwd
> /mnt/usr
> $ ls -l
> total 0
> drwxr-xr-x  1 root root  0 Feb 15  2005 X11R6
> drwxr-xr-x  1 root root  0 Jan 16  2007 bin
> drwxr-xr-x  1 root root  0 Jan 16  2007 doc
> drwxr-xr-x  1 root root  0 Feb 10  2005 games
> drwxr-xr-x  1 root root  0 Jan 16  2007 include
> lrwxr-xr-x  1 root root 10 Jan 16  2007 info -> share/info
> drwxr-xr-x  1 root root  0 Jan 16  2007 lib
> drwxr-xr-x  1 root root  0 Feb 10  2005 local
> drwxr-xr-x  1 root root  0 Jan 16  2007 sbin
> drwxr-xr-x  1 root root  0 Jan  5  2006 share
> drwxr-xr-x  1 root root  0 Dec 15  2004 src
> $ ls -l info/
> total 249856
> -rwxr-xr-x  1 root root 150109 Jul 16  2004 coreutils.info.gz
> -rwxr-xr-x  1 root root   1299 Jan 16  2007 dir
> -rwxr-xr-x  1 root root   1299 Jan 16  2007 dir.old
> -rwxr-xr-x  1 root root  28019 Mar 20  2005 find.info.gz
> -rwxr-xr-x  1 root root  26136 Nov 22  2004 grep.info.gz
> -rwxr-xr-x  1 root root  12914 Sep 16  2006 gzip.info.gz
> -rwxr-xr-x  1 root root  12316 Sep 18  2005 ipc.info.gz
> -rwxr-xr-x  1 root root  21432 Jan 23  2005 rl5userman.info.gz
> -rwxr-xr-x  1 root root  26647 Dec  1  2004 sed.info.gz
> -rwxr-xr-x  1 root root 123382 Dec  1  2006 tar.info.gz
> -rwxr-xr-x  1 root root  54876 May 23  2005 wget.info.gz
> $ cd ../bin
> $ ls -l sh
> lrwxr-xr-x  1 root root 4 Jan 16  2007 sh -> bash
> $ dd if=sh bs=1 count=6
> ELF6+0 records in
> 6+0 records out
> 6 bytes transferred in 0.001432 seconds (4190 bytes/sec)
> 
> As you can see I now can see the symbolic links perfectly and they work as
> expected.
> 
> In fact, this patch is working so well that it poses a security risk, as now
> the devices on my /mnt/dev directory are not only seen as devices (like they
> were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).

Why do you consider this a security problem ? Is any user able to create a
device entry with enough permissions ? As a general rule of thumb, networked
file systems should be mounted with the "nodev" option.

> So... for me now the remote filesystem works as if it was a local
> filesystem, without any difference of behaviour, not even on special files
> like devices or whatever.
> 
> As I said before... this behaviour of having the remote device files work...
> seems a security problem and I don't think is desirable, other than that it
> seems to work well on my PowerPC, I'll try to run the tests on a normal x86
> client and report back.

Thanks very much for your tests.

Grant, just to be sure, are you really certain that you tried the fixed kernel ?
It is 

Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Santiago Garcia Mantinan
Hi again!

I tried to replicate the problem at home during the weekend with my laptop,
but I couldn't get it to show links with previous kernels, so I guess I had
something different on my samba server or similar, I'm at the real machines
now so I have done the real tests and they look promising. I'm getting
completely different results than those of Grant, which seems really weird.

I applied just this patch:

> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
> > >17:53:57.247695476 -0700
> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
> > >-0700
> > >@@ -1997,7 +1997,7 @@
> > >   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> > > S_IRWXO)) | S_IFDIR;
> > >   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> > > !(S_ISDIR(fattr->f_mode)) )
> > >-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | S_IFREG;
> > >+  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> > >S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > > 
> > > }

To an unpatched 2.4.34, the client is an IBM NetworkStation 1000 (a PowerPC
based thin client), and the server is a normal amd64 based PC running
2.6.19.1, both running Debian, the client runs Sarge and the Server Etch.
I'm descriving this to see if differences on the architectures could be
causing the differences on behaviour between my tests and Grant's.

> > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
> > eliminate it from the problem space (hopefully ;) :
> > [EMAIL PROTECTED]:/home/other$ uname -r
> > 2.4.34b
> > [EMAIL PROTECTED]:/home/other$ ls -l
> > total 9
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
> 
> It seems to me that there is a difference, because filelink now appears the
> same size as file. It's just as if we had hard links instead of symlinks.

Here is what I did, I mounted the remote filesystem on /mnt on my client,
the share on the server has a normal Debian Sarge PowerPC filesystem on it.

$ pwd
/mnt/usr
$ ls -l
total 0
drwxr-xr-x  1 root root  0 Feb 15  2005 X11R6
drwxr-xr-x  1 root root  0 Jan 16  2007 bin
drwxr-xr-x  1 root root  0 Jan 16  2007 doc
drwxr-xr-x  1 root root  0 Feb 10  2005 games
drwxr-xr-x  1 root root  0 Jan 16  2007 include
lrwxr-xr-x  1 root root 10 Jan 16  2007 info -> share/info
drwxr-xr-x  1 root root  0 Jan 16  2007 lib
drwxr-xr-x  1 root root  0 Feb 10  2005 local
drwxr-xr-x  1 root root  0 Jan 16  2007 sbin
drwxr-xr-x  1 root root  0 Jan  5  2006 share
drwxr-xr-x  1 root root  0 Dec 15  2004 src
$ ls -l info/
total 249856
-rwxr-xr-x  1 root root 150109 Jul 16  2004 coreutils.info.gz
-rwxr-xr-x  1 root root   1299 Jan 16  2007 dir
-rwxr-xr-x  1 root root   1299 Jan 16  2007 dir.old
-rwxr-xr-x  1 root root  28019 Mar 20  2005 find.info.gz
-rwxr-xr-x  1 root root  26136 Nov 22  2004 grep.info.gz
-rwxr-xr-x  1 root root  12914 Sep 16  2006 gzip.info.gz
-rwxr-xr-x  1 root root  12316 Sep 18  2005 ipc.info.gz
-rwxr-xr-x  1 root root  21432 Jan 23  2005 rl5userman.info.gz
-rwxr-xr-x  1 root root  26647 Dec  1  2004 sed.info.gz
-rwxr-xr-x  1 root root 123382 Dec  1  2006 tar.info.gz
-rwxr-xr-x  1 root root  54876 May 23  2005 wget.info.gz
$ cd ../bin
$ ls -l sh
lrwxr-xr-x  1 root root 4 Jan 16  2007 sh -> bash
$ dd if=sh bs=1 count=6
ELF6+0 records in
6+0 records out
6 bytes transferred in 0.001432 seconds (4190 bytes/sec)

As you can see I now can see the symbolic links perfectly and they work as
expected.

In fact, this patch is working so well that it poses a security risk, as now
the devices on my /mnt/dev directory are not only seen as devices (like they
were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).

So... for me now the remote filesystem works as if it was a local
filesystem, without any difference of behaviour, not even on special files
like devices or whatever.

As I said before... this behaviour of having the remote device files work...
seems a security problem and I don't think is desirable, other than that it
seems to work well on my PowerPC, I'll try to run the tests on a normal x86
client and report back.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Santiago Garcia Mantinan
Hi again!

I tried to replicate the problem at home during the weekend with my laptop,
but I couldn't get it to show links with previous kernels, so I guess I had
something different on my samba server or similar, I'm at the real machines
now so I have done the real tests and they look promising. I'm getting
completely different results than those of Grant, which seems really weird.

I applied just this patch:

  --- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 
  17:53:57.247695476 -0700
  +++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
  -0700
  @@ -1997,7 +1997,7 @@
 fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
   S_IRWXO)) | S_IFDIR;
 else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
   !(S_ISDIR(fattr-f_mode)) )
  -  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFREG;
  +  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | (fattr-f_mode  S_IFMT);
   
   }

To an unpatched 2.4.34, the client is an IBM NetworkStation 1000 (a PowerPC
based thin client), and the server is a normal amd64 based PC running
2.6.19.1, both running Debian, the client runs Sarge and the Server Etch.
I'm descriving this to see if differences on the architectures could be
causing the differences on behaviour between my tests and Grant's.

  client running 2.4.34 with above patch, server is running 2.6.19.2 to 
  eliminate it from the problem space (hopefully ;) :
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ ls -l
  total 9
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
 
 It seems to me that there is a difference, because filelink now appears the
 same size as file. It's just as if we had hard links instead of symlinks.

Here is what I did, I mounted the remote filesystem on /mnt on my client,
the share on the server has a normal Debian Sarge PowerPC filesystem on it.

$ pwd
/mnt/usr
$ ls -l
total 0
drwxr-xr-x  1 root root  0 Feb 15  2005 X11R6
drwxr-xr-x  1 root root  0 Jan 16  2007 bin
drwxr-xr-x  1 root root  0 Jan 16  2007 doc
drwxr-xr-x  1 root root  0 Feb 10  2005 games
drwxr-xr-x  1 root root  0 Jan 16  2007 include
lrwxr-xr-x  1 root root 10 Jan 16  2007 info - share/info
drwxr-xr-x  1 root root  0 Jan 16  2007 lib
drwxr-xr-x  1 root root  0 Feb 10  2005 local
drwxr-xr-x  1 root root  0 Jan 16  2007 sbin
drwxr-xr-x  1 root root  0 Jan  5  2006 share
drwxr-xr-x  1 root root  0 Dec 15  2004 src
$ ls -l info/
total 249856
-rwxr-xr-x  1 root root 150109 Jul 16  2004 coreutils.info.gz
-rwxr-xr-x  1 root root   1299 Jan 16  2007 dir
-rwxr-xr-x  1 root root   1299 Jan 16  2007 dir.old
-rwxr-xr-x  1 root root  28019 Mar 20  2005 find.info.gz
-rwxr-xr-x  1 root root  26136 Nov 22  2004 grep.info.gz
-rwxr-xr-x  1 root root  12914 Sep 16  2006 gzip.info.gz
-rwxr-xr-x  1 root root  12316 Sep 18  2005 ipc.info.gz
-rwxr-xr-x  1 root root  21432 Jan 23  2005 rl5userman.info.gz
-rwxr-xr-x  1 root root  26647 Dec  1  2004 sed.info.gz
-rwxr-xr-x  1 root root 123382 Dec  1  2006 tar.info.gz
-rwxr-xr-x  1 root root  54876 May 23  2005 wget.info.gz
$ cd ../bin
$ ls -l sh
lrwxr-xr-x  1 root root 4 Jan 16  2007 sh - bash
$ dd if=sh bs=1 count=6
ELF6+0 records in
6+0 records out
6 bytes transferred in 0.001432 seconds (4190 bytes/sec)

As you can see I now can see the symbolic links perfectly and they work as
expected.

In fact, this patch is working so well that it poses a security risk, as now
the devices on my /mnt/dev directory are not only seen as devices (like they
were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).

So... for me now the remote filesystem works as if it was a local
filesystem, without any difference of behaviour, not even on special files
like devices or whatever.

As I said before... this behaviour of having the remote device files work...
seems a security problem and I don't think is desirable, other than that it
seems to work well on my PowerPC, I'll try to run the tests on a normal x86
client and report back.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Willy Tarreau
Hi Santiago !

On Mon, Jan 22, 2007 at 09:54:00AM +0100, Santiago Garcia Mantinan wrote:
 Hi again!
 
 I tried to replicate the problem at home during the weekend with my laptop,
 but I couldn't get it to show links with previous kernels, so I guess I had
 something different on my samba server or similar, I'm at the real machines
 now so I have done the real tests and they look promising. I'm getting
 completely different results than those of Grant, which seems really weird.
 
 I applied just this patch:
 
   --- kernel-source-2.4.27.orig/fs/smbfs/proc.c2007-01-19 
   17:53:57.247695476 -0700
   +++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 
   -0700
   @@ -1997,7 +1997,7 @@
fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | 
S_IRWXG | S_IRWXO)) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
   -fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | 
   S_IRWXG | S_IRWXO)) | S_IFREG;
   +fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | 
   S_IRWXG | S_IRWXO)) | (fattr-f_mode  S_IFMT);

}
 
 To an unpatched 2.4.34, the client is an IBM NetworkStation 1000 (a PowerPC
 based thin client), and the server is a normal amd64 based PC running
 2.6.19.1, both running Debian, the client runs Sarge and the Server Etch.
 I'm descriving this to see if differences on the architectures could be
 causing the differences on behaviour between my tests and Grant's.
 
   client running 2.4.34 with above patch, server is running 2.6.19.2 to 
   eliminate it from the problem space (hopefully ;) :
   [EMAIL PROTECTED]:/home/other$ uname -r
   2.4.34b
   [EMAIL PROTECTED]:/home/other$ ls -l
   total 9
   drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
   drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
   -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
   -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
  
  It seems to me that there is a difference, because filelink now appears the
  same size as file. It's just as if we had hard links instead of symlinks.
 
 Here is what I did, I mounted the remote filesystem on /mnt on my client,
 the share on the server has a normal Debian Sarge PowerPC filesystem on it.
 
 $ pwd
 /mnt/usr
 $ ls -l
 total 0
 drwxr-xr-x  1 root root  0 Feb 15  2005 X11R6
 drwxr-xr-x  1 root root  0 Jan 16  2007 bin
 drwxr-xr-x  1 root root  0 Jan 16  2007 doc
 drwxr-xr-x  1 root root  0 Feb 10  2005 games
 drwxr-xr-x  1 root root  0 Jan 16  2007 include
 lrwxr-xr-x  1 root root 10 Jan 16  2007 info - share/info
 drwxr-xr-x  1 root root  0 Jan 16  2007 lib
 drwxr-xr-x  1 root root  0 Feb 10  2005 local
 drwxr-xr-x  1 root root  0 Jan 16  2007 sbin
 drwxr-xr-x  1 root root  0 Jan  5  2006 share
 drwxr-xr-x  1 root root  0 Dec 15  2004 src
 $ ls -l info/
 total 249856
 -rwxr-xr-x  1 root root 150109 Jul 16  2004 coreutils.info.gz
 -rwxr-xr-x  1 root root   1299 Jan 16  2007 dir
 -rwxr-xr-x  1 root root   1299 Jan 16  2007 dir.old
 -rwxr-xr-x  1 root root  28019 Mar 20  2005 find.info.gz
 -rwxr-xr-x  1 root root  26136 Nov 22  2004 grep.info.gz
 -rwxr-xr-x  1 root root  12914 Sep 16  2006 gzip.info.gz
 -rwxr-xr-x  1 root root  12316 Sep 18  2005 ipc.info.gz
 -rwxr-xr-x  1 root root  21432 Jan 23  2005 rl5userman.info.gz
 -rwxr-xr-x  1 root root  26647 Dec  1  2004 sed.info.gz
 -rwxr-xr-x  1 root root 123382 Dec  1  2006 tar.info.gz
 -rwxr-xr-x  1 root root  54876 May 23  2005 wget.info.gz
 $ cd ../bin
 $ ls -l sh
 lrwxr-xr-x  1 root root 4 Jan 16  2007 sh - bash
 $ dd if=sh bs=1 count=6
 ELF6+0 records in
 6+0 records out
 6 bytes transferred in 0.001432 seconds (4190 bytes/sec)
 
 As you can see I now can see the symbolic links perfectly and they work as
 expected.
 
 In fact, this patch is working so well that it poses a security risk, as now
 the devices on my /mnt/dev directory are not only seen as devices (like they
 were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).

Why do you consider this a security problem ? Is any user able to create a
device entry with enough permissions ? As a general rule of thumb, networked
file systems should be mounted with the nodev option.

 So... for me now the remote filesystem works as if it was a local
 filesystem, without any difference of behaviour, not even on special files
 like devices or whatever.
 
 As I said before... this behaviour of having the remote device files work...
 seems a security problem and I don't think is desirable, other than that it
 seems to work well on my PowerPC, I'll try to run the tests on a normal x86
 client and report back.

Thanks very much for your tests.

Grant, just to be sure, are you really certain that you tried the fixed kernel ?
It is possible that you booted a wrong kernel during one of your tests. I'm
intrigued by the fact that it changed nothing for you and that it fixed the
problem for Santiago.

Best regards,
Willy

-
To 

Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Santiago Garcia Mantinan
  As you can see I now can see the symbolic links perfectly and they work as
  expected.
  
  In fact, this patch is working so well that it poses a security risk, as now
  the devices on my /mnt/dev directory are not only seen as devices (like they
  were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
 
 Why do you consider this a security problem ? Is any user able to create a
 device entry with enough permissions ? As a general rule of thumb, networked
 file systems should be mounted with the nodev option.

You are completely right on that, it is just that I thought those devices
didn't work on 2.4.33, but I just retested again and they work ok, only that
they were not working to me on the PC I tested the other day and it was
because of a nodev option :-) just that.

So... I have finised with my tests, I have tested an x86 client on which it
worked ok, just like on the PowerPC client, both working perfectly just like
they used to do on 2.4.33.

 Grant, just to be sure, are you really certain that you tried the fixed 
 kernel ?
 It is possible that you booted a wrong kernel during one of your tests. I'm
 intrigued by the fact that it changed nothing for you and that it fixed the
 problem for Santiago.

Maybe he had also applied some of the earlier patches you had sent and that
I did not apply to mine?

Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
I'm running a pristine kernel with just this latest patch applied, the one
that changes S_IFREG for (fattr-f_mode  S_IFMT).

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Grant Coady
On Mon, 22 Jan 2007 10:18:16 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Grant, just to be sure, are you really certain that you tried the fixed kernel 
?
It is possible that you booted a wrong kernel during one of your tests. I'm
intrigued by the fact that it changed nothing for you and that it fixed the
problem for Santiago.

Closest I get to Santiago's results are with the 2.4.33.7 plus the patch, 
with 'use default NLS' option turned on, as well as the unix extensions.

2.4.34 was a no go for me.  Changing the default NLS made no difference, 
now trying with unix extensions turned on. . .  Yeah, that works, apart 
from the test file gaining execute bits, compared to operation under 
2.4.33.3, this is 2.4.34 + patch + default NLS and unix extensions:

[EMAIL PROTECTED]:/home/other$ cat dirlink/filelink
this is a test
[EMAIL PROTECTED]:/home/other$ echo this is a test  testfile
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
drwxr-xr-x 1 grant wheel  0 2007-01-22 10:45 test/
-rwxr-xr-x 1 grant wheel 15 2007-01-22 21:31 testfile*
lrwxr-xr-x 1 grant wheel  4 2007-01-22 21:29 testlink - test/
[EMAIL PROTECTED]:/home/other$ ln -s testfile testfilelink
[EMAIL PROTECTED]:/home/other$ cat testfilelink
this is a test


The fix depends on the smbfs configuration?  Is this the requirement?
I ask as the other mode of operation (unix extensions turned off): do 
not display symlinks, prevent creation of symlinks, seems to be logically 
self-consistent, as well as matching what I see from a 'doze box.

Grant.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Grant Coady
On Mon, 22 Jan 2007 10:36:30 +0100, Santiago Garcia Mantinan [EMAIL 
PROTECTED] wrote:

  As you can see I now can see the symbolic links perfectly and they work as
  expected.
  
  In fact, this patch is working so well that it poses a security risk, as 
  now
  the devices on my /mnt/dev directory are not only seen as devices (like 
  they
  were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
 
 Why do you consider this a security problem ? Is any user able to create a
 device entry with enough permissions ? As a general rule of thumb, networked
 file systems should be mounted with the nodev option.

You are completely right on that, it is just that I thought those devices
didn't work on 2.4.33, but I just retested again and they work ok, only that
they were not working to me on the PC I tested the other day and it was
because of a nodev option :-) just that.

So... I have finised with my tests, I have tested an x86 client on which it
worked ok, just like on the PowerPC client, both working perfectly just like
they used to do on 2.4.33.

 Grant, just to be sure, are you really certain that you tried the fixed 
 kernel ?
 It is possible that you booted a wrong kernel during one of your tests. I'm
 intrigued by the fact that it changed nothing for you and that it fixed the
 problem for Santiago.

Maybe he had also applied some of the earlier patches you had sent and that
I did not apply to mine?

Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
I'm running a pristine kernel with just this latest patch applied, the one
that changes S_IFREG for (fattr-f_mode  S_IFMT).

Same kernel + patch here for latest results posting :)  We seem to get 
similar results now -- though I query the file execute bits coming up.

Grant.

Regards...

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread dann frazier
On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
 On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.34b
 [EMAIL PROTECTED]:/home/other$ mkdir test
 [EMAIL PROTECTED]:/home/other$ ln -s test testlink
 ln: creating symbolic link `testlink' to `test': Operation not permitted
 [EMAIL PROTECTED]:/home/other$ echo this is also a test  test/file
 [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
 ln: creating symbolic link `test2' to `test/file': Operation not permitted
 
 trying to create symlinks.
 
 No problems creating symlinks with 2.4.33.3.

Yes, I've found that this varies depending upon the options passed. If
uid=0, I can create symlinks, otherwise I always get permission
denied. This behavior appears to be consistent with 2.6.

I also need to do some testing with the proposed patch to smbmount
that will let you omit options (current versions will always pass an
option to the kernel, even if you the user did not provide one).
If you do not pass options, the behavior should fallback to
server-provided values.

Note that this bug has been my only interaction with smbfs, so I'm
certainly no expert on how it *should* behave. My plan is to
take all of the use cases we're coming up with and try to maintain
the historic 2.4 behavior as much as possible, but still not
silently dropping user-provided mount options. When the behavior needs
to change to honor them, I'll try to match what current 2.6
does. Make sense?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-22 Thread Willy Tarreau
Hi Dann,

On Mon, Jan 22, 2007 at 11:19:43AM -0700, dann frazier wrote:
 On Mon, Jan 22, 2007 at 10:50:47AM +1100, Grant Coady wrote:
  On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ mkdir test
  [EMAIL PROTECTED]:/home/other$ ln -s test testlink
  ln: creating symbolic link `testlink' to `test': Operation not permitted
  [EMAIL PROTECTED]:/home/other$ echo this is also a test  test/file
  [EMAIL PROTECTED]:/home/other$ ln -s test/file test2
  ln: creating symbolic link `test2' to `test/file': Operation not permitted
  
  trying to create symlinks.
  
  No problems creating symlinks with 2.4.33.3.
 
 Yes, I've found that this varies depending upon the options passed. If
 uid=0, I can create symlinks, otherwise I always get permission
 denied. This behavior appears to be consistent with 2.6.
 
 I also need to do some testing with the proposed patch to smbmount
 that will let you omit options (current versions will always pass an
 option to the kernel, even if you the user did not provide one).
 If you do not pass options, the behavior should fallback to
 server-provided values.
 
 Note that this bug has been my only interaction with smbfs, so I'm
 certainly no expert on how it *should* behave. My plan is to
 take all of the use cases we're coming up with and try to maintain
 the historic 2.4 behavior as much as possible, but still not
 silently dropping user-provided mount options. When the behavior needs
 to change to honor them, I'll try to match what current 2.6
 does. Make sense?

Yes, it does for me. So to sum up, I apply your patch to 2.4.34.1
and it restores the same behaviour for Santiago and Grant as they get
in 2.6. Whether it's the expected behaviour or not is not the point,
as it will be easier for us to later mimic 2.6 if a change is needed
since we're not experts at all in this area.

If we're all OK for this, I'll go with that.

Thanks guys,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>Ah, think I see the problem now:
>
>--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 17:53:57.247695476 
>-0700
>+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
>-0700
>@@ -1997,7 +1997,7 @@
>   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> S_IRWXO)) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFREG;
>+  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | (fattr->f_mode & S_IFMT);
> 
> }
> 
client running 2.4.34 with above patch, server is running 2.6.19.2 to 
eliminate it from the problem space (hopefully ;) :
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ ls -l
total 9
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 1
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
[EMAIL PROTECTED]:/home/other$

problem is still there :(

With client 2.4.33.3 (slackware-11 distro kernel):
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 2048
drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root root 15 2007-01-21 11:43 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 2048
-rw-r--r-- 1 root root 15 2007-01-21 11:44 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
[EMAIL PROTECTED]:/home/other$ cat filelink
this is a test

No problem with symlinks, execute flag.

Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hi Grant !
>
>On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
>> On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
>> 
>> >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>> >Ah, think I see the problem now:
>> >
>> >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 
>> >17:53:57.247695476 -0700
>> >+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
>> >-0700
>> >@@ -1997,7 +1997,7 @@
>> >fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>> > S_IRWXO)) | S_IFDIR;
>> >else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
>> >  !(S_ISDIR(fattr->f_mode)) )
>> >-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> >S_IRWXO)) | S_IFREG;
>> >+   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> >S_IRWXO)) | (fattr->f_mode & S_IFMT);
>> > 
>> > }
>> > 
>> client running 2.4.34 with above patch, server is running 2.6.19.2 to 
>> eliminate it from the problem space (hopefully ;) :
>> [EMAIL PROTECTED]:/home/other$ uname -r
>> 2.4.34b
>> [EMAIL PROTECTED]:/home/other$ ls -l
>> total 9
>> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
>> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
>> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
>> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
>
>It seems to me that there is a difference, because filelink now appears the
>same size as file. It's just as if we had hard links instead of symlinks.

Hi Willy,

No, those dir and files were created server-side, sorry I gave wrong 
impression, I still get on client side:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ mkdir test
[EMAIL PROTECTED]:/home/other$ ln -s test testlink
ln: creating symbolic link `testlink' to `test': Operation not permitted
[EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file
[EMAIL PROTECTED]:/home/other$ ln -s test/file test2
ln: creating symbolic link `test2' to `test/file': Operation not permitted

trying to create symlinks.

No problems creating symlinks with 2.4.33.3.

Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Thu, 18 Jan 2007 05:21:16 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hi Grant !
>
>On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
>(...)
>> >} else {
>> >-   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >-   S_IROTH | S_IXOTH | S_IFREG;
>> >-   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >-   S_IROTH | S_IXOTH | S_IFDIR;
>> >+   mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
>> >+   mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+   S_IROTH | S_IXOTH | S_IFDIR;
>> >if (parse_options(mnt, raw_data))
>> >goto out_bad_option;
>> 
>> I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
>> to directories seen as target, nor can they be created (Operation not 
>> permitted...)
>
>Thanks very much Grant for the test. Could you try a symlink to a file ?

"Operation not permitted"

>And while we're at it, would you like to try to add "|S_IFLNK" to
>mnt->dir_mode ? If my suggestion was stupid, at least let's test it to
>full extent ;-)

Yep, already tried the obvious ;)  no difference :(

2.4.33.5 onwards also have a problem with symlinks, but it is slightly 
different presentation, the directory symlinks appear as normal files.

With 2.4.33.7 one is able to create file and directory symlinks, though 
the links appear as files.  Content problem as noted by OP:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.7
[EMAIL PROTECTED]:/home/other$ cat file
this is a test
[EMAIL PROTECTED]:/home/other$ cat filelink
[EMAIL PROTECTED]:/home/other$

[EMAIL PROTECTED]:/home/other$ mkdir directory
[EMAIL PROTECTED]:/home/other$ ln -s directory directorylink
[EMAIL PROTECTED]:/home/other$ cp file* directory
[EMAIL PROTECTED]:/home/other$ ls directory
file*  filelink*
[EMAIL PROTECTED]:/home/other$ ls directorylink
directorylink*

Now, WinXP sees the contents of directorylink:

X:\>cd directorylink

X:\directorylink>dir
 Volume in drive X is other
 Volume Serial Number is 107E-052F

 Directory of X:\directorylink

2007-01-18  16:36  .
2007-01-18  16:33  ..
2007-01-18  16:3615 file
2007-01-18  16:36 4 filelink
   2 File(s) 19 bytes
   2 Dir(s)   2,558,922,752 bytes free

X:\directorylink>type file
this is a test

X:\directorylink>type filelink
this
X:\directorylink>
>
>I had another idea looking at the code but since I really don't know it,
>I would not like to propose random changes till this magically works. I'd
>wait for Dann who understood the code.

Grant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Willy Tarreau
Hi Grant !

On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
> On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> 
> >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> >Ah, think I see the problem now:
> >
> >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c2007-01-19 
> >17:53:57.247695476 -0700
> >+++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 
> >-0700
> >@@ -1997,7 +1997,7 @@
> > fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> > S_IRWXO)) | S_IFDIR;
> > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> >   !(S_ISDIR(fattr->f_mode)) )
> >-fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> >S_IRWXO)) | S_IFREG;
> >+fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> >S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > 
> > }
> > 
> client running 2.4.34 with above patch, server is running 2.6.19.2 to 
> eliminate it from the problem space (hopefully ;) :
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.34b
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 9
> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*

It seems to me that there is a difference, because filelink now appears the
same size as file. It's just as if we had hard links instead of symlinks.

> [EMAIL PROTECTED]:/home/other$ ls -l dirlink/
> total 1
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
> [EMAIL PROTECTED]:/home/other$
> 
> problem is still there :(

At least, directories appear as hard links too.

> With client 2.4.33.3 (slackware-11 distro kernel):
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.33.3
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 2048
> drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root root 15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
> [EMAIL PROTECTED]:/home/other$ ls -l dirlink/
> total 2048
> -rw-r--r-- 1 root root 15 2007-01-21 11:44 file
> lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
> [EMAIL PROTECTED]:/home/other$ cat filelink
> this is a test
> 
> No problem with symlinks, execute flag.
>
> Grant.

Thanks for your tests !
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Willy Tarreau
Hi Grant !

On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
 On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
 
 On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 Ah, think I see the problem now:
 
 --- kernel-source-2.4.27.orig/fs/smbfs/proc.c2007-01-19 
 17:53:57.247695476 -0700
 +++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 
 -0700
 @@ -1997,7 +1997,7 @@
  fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFDIR;
  else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
!(S_ISDIR(fattr-f_mode)) )
 -fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFREG;
 +fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | (fattr-f_mode  S_IFMT);
  
  }
  
 client running 2.4.34 with above patch, server is running 2.6.19.2 to 
 eliminate it from the problem space (hopefully ;) :
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.34b
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 9
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*

It seems to me that there is a difference, because filelink now appears the
same size as file. It's just as if we had hard links instead of symlinks.

 [EMAIL PROTECTED]:/home/other$ ls -l dirlink/
 total 1
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
 -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
 [EMAIL PROTECTED]:/home/other$
 
 problem is still there :(

At least, directories appear as hard links too.

 With client 2.4.33.3 (slackware-11 distro kernel):
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.33.3
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 2048
 drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
 lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink - dir/
 -rw-r--r-- 1 root root 15 2007-01-21 11:43 file
 lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
 [EMAIL PROTECTED]:/home/other$ ls -l dirlink/
 total 2048
 -rw-r--r-- 1 root root 15 2007-01-21 11:44 file
 lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
 [EMAIL PROTECTED]:/home/other$ cat filelink
 this is a test
 
 No problem with symlinks, execute flag.

 Grant.

Thanks for your tests !
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hi Grant !

On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
 On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
 
 On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 Ah, think I see the problem now:
 
 --- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 
 17:53:57.247695476 -0700
 +++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
 -0700
 @@ -1997,7 +1997,7 @@
 fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFDIR;
 else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
   !(S_ISDIR(fattr-f_mode)) )
 -   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFREG;
 +   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | (fattr-f_mode  S_IFMT);
  
  }
  
 client running 2.4.34 with above patch, server is running 2.6.19.2 to 
 eliminate it from the problem space (hopefully ;) :
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.34b
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 9
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*

It seems to me that there is a difference, because filelink now appears the
same size as file. It's just as if we had hard links instead of symlinks.

Hi Willy,

No, those dir and files were created server-side, sorry I gave wrong 
impression, I still get on client side:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ mkdir test
[EMAIL PROTECTED]:/home/other$ ln -s test testlink
ln: creating symbolic link `testlink' to `test': Operation not permitted
[EMAIL PROTECTED]:/home/other$ echo this is also a test  test/file
[EMAIL PROTECTED]:/home/other$ ln -s test/file test2
ln: creating symbolic link `test2' to `test/file': Operation not permitted

trying to create symlinks.

No problems creating symlinks with 2.4.33.3.

Grant.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Thu, 18 Jan 2007 05:21:16 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hi Grant !

On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
(...)
 } else {
 -   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -   S_IROTH | S_IXOTH | S_IFREG;
 -   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -   S_IROTH | S_IXOTH | S_IFDIR;
 +   mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
 +   mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +   S_IROTH | S_IXOTH | S_IFDIR;
 if (parse_options(mnt, raw_data))
 goto out_bad_option;
 
 I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
 to directories seen as target, nor can they be created (Operation not 
 permitted...)

Thanks very much Grant for the test. Could you try a symlink to a file ?

Operation not permitted

And while we're at it, would you like to try to add |S_IFLNK to
mnt-dir_mode ? If my suggestion was stupid, at least let's test it to
full extent ;-)

Yep, already tried the obvious ;)  no difference :(

2.4.33.5 onwards also have a problem with symlinks, but it is slightly 
different presentation, the directory symlinks appear as normal files.

With 2.4.33.7 one is able to create file and directory symlinks, though 
the links appear as files.  Content problem as noted by OP:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.7
[EMAIL PROTECTED]:/home/other$ cat file
this is a test
[EMAIL PROTECTED]:/home/other$ cat filelink
[EMAIL PROTECTED]:/home/other$

[EMAIL PROTECTED]:/home/other$ mkdir directory
[EMAIL PROTECTED]:/home/other$ ln -s directory directorylink
[EMAIL PROTECTED]:/home/other$ cp file* directory
[EMAIL PROTECTED]:/home/other$ ls directory
file*  filelink*
[EMAIL PROTECTED]:/home/other$ ls directorylink
directorylink*

Now, WinXP sees the contents of directorylink:

X:\cd directorylink

X:\directorylinkdir
 Volume in drive X is other
 Volume Serial Number is 107E-052F

 Directory of X:\directorylink

2007-01-18  16:36DIR  .
2007-01-18  16:33DIR  ..
2007-01-18  16:3615 file
2007-01-18  16:36 4 filelink
   2 File(s) 19 bytes
   2 Dir(s)   2,558,922,752 bytes free

X:\directorylinktype file
this is a test

X:\directorylinktype filelink
this
X:\directorylink

I had another idea looking at the code but since I really don't know it,
I would not like to propose random changes till this magically works. I'd
wait for Dann who understood the code.

Grant.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-21 Thread Grant Coady
On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
   fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFDIR;
   else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
 !(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr-f_mode  S_IFMT);
 
 }
 
client running 2.4.34 with above patch, server is running 2.6.19.2 to 
eliminate it from the problem space (hopefully ;) :
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ ls -l
total 9
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 1
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
[EMAIL PROTECTED]:/home/other$

problem is still there :(

With client 2.4.33.3 (slackware-11 distro kernel):
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 2048
drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root root 15 2007-01-21 11:43 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 2048
-rw-r--r-- 1 root root 15 2007-01-21 11:44 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
[EMAIL PROTECTED]:/home/other$ cat filelink
this is a test

No problem with symlinks, execute flag.

Grant.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-19 Thread Willy Tarreau
On Fri, Jan 19, 2007 at 06:05:44PM -0700, dann frazier wrote:
(...)
> Ah, think I see the problem now:
> 
> --- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.247695476 
> -0700
> +++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
> -0700
> @@ -1997,7 +1997,7 @@
>   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> S_IRWXO)) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
> - fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> S_IRWXO)) | S_IFREG;
> + fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
> S_IRWXO)) | (fattr->f_mode & S_IFMT);
>  
>  }
>  
> Santiago: Thanks for reporting this - can you test this patch out on
> your system and let me know if there are still any problems?
> 
> Willy: I'll do some more testing and get you a patch that fixes this
> and the double assignment nonsense. Would you prefer a single patch or
> two?

Since the double assignment is not a bug per se, don't bother making a
separate patch, put everything in the same one.

Thanks a lot for your very fast response !

Cheers,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-19 Thread dann frazier
On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> > @@ -505,8 +510,13 @@
> > mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> > mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> >  
> > -   mnt->flags = (oldmnt->file_mode >> 9);
> > +   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> > +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> > } else {
> > +   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFREG;
> > +   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> > }
> > 
> > 
> > See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> > expected thing like this but I wonder if the initial intent was
> > exactly this.
> 
> Wow - sorry about that, that's certainly a cut & paste error. But the
> end result appears to match current 2.6, which was the intent.
> 
> > Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> > what I say is stupid, but it's just a guess.
> 
> I really don't know the correct answer to that, I was merely copying
> the 2.6 flags. 
> 
> [Still working on getting a 2.4 smbfs test system up...]

Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
  !(S_ISDIR(fattr->f_mode)) )
-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr->f_mode & S_IFMT);
 
 }
 
Santiago: Thanks for reporting this - can you test this patch out on
your system and let me know if there are still any problems?

Willy: I'll do some more testing and get you a patch that fixes this
and the double assignment nonsense. Would you prefer a single patch or
two?

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-19 Thread dann frazier
On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
  @@ -505,8 +510,13 @@
  mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
  mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
   
  -   mnt-flags = (oldmnt-file_mode  9);
  +   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
  +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
  } else {
  +   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFREG;
  +   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFDIR;
  if (parse_options(mnt, raw_data))
  goto out_bad_option;
  }
  
  
  See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
  expected thing like this but I wonder if the initial intent was
  exactly this.
 
 Wow - sorry about that, that's certainly a cut  paste error. But the
 end result appears to match current 2.6, which was the intent.
 
  Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
  what I say is stupid, but it's just a guess.
 
 I really don't know the correct answer to that, I was merely copying
 the 2.6 flags. 
 
 [Still working on getting a 2.4 smbfs test system up...]

Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
-   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr-f_mode  S_IFMT);
 
 }
 
Santiago: Thanks for reporting this - can you test this patch out on
your system and let me know if there are still any problems?

Willy: I'll do some more testing and get you a patch that fixes this
and the double assignment nonsense. Would you prefer a single patch or
two?

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-19 Thread Willy Tarreau
On Fri, Jan 19, 2007 at 06:05:44PM -0700, dann frazier wrote:
(...)
 Ah, think I see the problem now:
 
 --- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.247695476 
 -0700
 +++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
 -0700
 @@ -1997,7 +1997,7 @@
   fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFDIR;
   else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
 !(S_ISDIR(fattr-f_mode)) )
 - fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFREG;
 + fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | (fattr-f_mode  S_IFMT);
  
  }
  
 Santiago: Thanks for reporting this - can you test this patch out on
 your system and let me know if there are still any problems?
 
 Willy: I'll do some more testing and get you a patch that fixes this
 and the double assignment nonsense. Would you prefer a single patch or
 two?

Since the double assignment is not a bug per se, don't bother making a
separate patch, put everything in the same one.

Thanks a lot for your very fast response !

Cheers,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread Willy Tarreau
Hi Dann !

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> > @@ -505,8 +510,13 @@
> > mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> > mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> >  
> > -   mnt->flags = (oldmnt->file_mode >> 9);
> > +   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> > +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> > } else {
> > +   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFREG;
> > +   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > +   S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> > }
> > 
> > 
> > See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> > expected thing like this but I wonder if the initial intent was
> > exactly this.
> 
> Wow - sorry about that, that's certainly a cut & paste error. But the
> end result appears to match current 2.6, which was the intent.

OK.

> > Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> > what I say is stupid, but it's just a guess.
> 
> I really don't know the correct answer to that, I was merely copying
> the 2.6 flags. 

Don't waste your time on this one, it did not work.

> [Still working on getting a 2.4 smbfs test system up...]

Thanks !

Best regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread dann frazier
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> @@ -505,8 +510,13 @@
>   mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
>   mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>  
> - mnt->flags = (oldmnt->file_mode >> 9);
> + mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
> + mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFREG;
> + mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> + S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
> 
> 
> See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> expected thing like this but I wonder if the initial intent was
> exactly this.

Wow - sorry about that, that's certainly a cut & paste error. But the
end result appears to match current 2.6, which was the intent.

> Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> what I say is stupid, but it's just a guess.

I really don't know the correct answer to that, I was merely copying
the 2.6 flags. 

[Still working on getting a 2.4 smbfs test system up...]

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread dann frazier
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> Dann, do you still have your samba server ready to try to reproduce this
> problem ? Also, there are very suspect lines right there in the patch :

I can set it up again, hopefully have some feedback by tomorrow.

-- 
dann frazier

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread dann frazier
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
 Dann, do you still have your samba server ready to try to reproduce this
 problem ? Also, there are very suspect lines right there in the patch :

I can set it up again, hopefully have some feedback by tomorrow.

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread dann frazier
On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
 @@ -505,8 +510,13 @@
   mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
   mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
  
 - mnt-flags = (oldmnt-file_mode  9);
 + mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
 + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
 + mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 + S_IROTH | S_IXOTH | S_IFREG;
 + mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 + S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }
 
 
 See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
 expected thing like this but I wonder if the initial intent was
 exactly this.

Wow - sorry about that, that's certainly a cut  paste error. But the
end result appears to match current 2.6, which was the intent.

 Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
 what I say is stupid, but it's just a guess.

I really don't know the correct answer to that, I was merely copying
the 2.6 flags. 

[Still working on getting a 2.4 smbfs test system up...]

-- 
dann frazier

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-18 Thread Willy Tarreau
Hi Dann !

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
  @@ -505,8 +510,13 @@
  mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
  mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
   
  -   mnt-flags = (oldmnt-file_mode  9);
  +   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
  +   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
  } else {
  +   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFREG;
  +   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
  +   S_IROTH | S_IXOTH | S_IFDIR;
  if (parse_options(mnt, raw_data))
  goto out_bad_option;
  }
  
  
  See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
  expected thing like this but I wonder if the initial intent was
  exactly this.
 
 Wow - sorry about that, that's certainly a cut  paste error. But the
 end result appears to match current 2.6, which was the intent.

OK.

  Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
  what I say is stupid, but it's just a guess.
 
 I really don't know the correct answer to that, I was merely copying
 the 2.6 flags. 

Don't waste your time on this one, it did not work.

 [Still working on getting a 2.4 smbfs test system up...]

Thanks !

Best regards,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Willy Tarreau
Hi Grant !

On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
(...)
> > } else {
> >-mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> >-S_IROTH | S_IXOTH | S_IFREG;
> >-mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> >-S_IROTH | S_IXOTH | S_IFDIR;
> >+mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> >+S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
> >+mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> >+S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> 
> I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
> to directories seen as target, nor can they be created (Operation not 
> permitted...)

Thanks very much Grant for the test. Could you try a symlink to a file ?
And while we're at it, would you like to try to add "|S_IFLNK" to
mnt->dir_mode ? If my suggestion was stupid, at least let's test it to
full extent ;-)

I had another idea looking at the code but since I really don't know it,
I would not like to propose random changes till this magically works. I'd
wait for Dann who understood the code.

Best regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Willy Tarreau
Hello Santiago,

On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
> Hi!
> 
> I have discovered a problem with the changes applied to smbfs in 2.4.34 and
> in the security backports like last Debian's 2.4 kernel update these changes
> seem to be made to solve CVE-2006-5871 and they have broken symbolic links
> and changed the way that special files (like devices) are seen.
> 
> For example:
> Before: symbolic links were seen as that, symbolic links an thus if you tried
> to open the file the link was followed and you ended up reading the
> destination file
> Now: symbolic links are seen as normal files (at least with a ls) but their
> length (N) is the length of the symbolic link, if you read it, you'll get the
> first N characters of the destination file. For example, on my filesystem
> bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
> get ELF (this is, the first 4 characters of the bash program, first one
> being a DEL).
> 
> Another example:
> Before: if you did a ls of a device file, like dev/zero you could see it as
> a device, if you tried opening it, it wouldn't work, but if you did a cp -a
> of that file to a local filesystem the result was a working zero device.
> Now: the devices are seen as normal files with a length of 0 bytes.
> 
> Seems to me like a mask is erasing some mode bits that shouldn't be erased.
> 
> I have carried my tests on a Debian Sarge machine always mounting the share
> using: smbmount //server/share /mnt without any other options. The tests
> were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
> Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
> samba 3.0.23d and I have experienced the same behaviour with samba's
> unix extensions = yes and unix extensions = no.
> 
> I don't know what else to add, if you need any more info or want me to do
> any tests just ask for it.

Well, there is not much to add there. Thanks very much for all your tests.
This problem was not easy to fix, and Dann Frazier did a careful job at
backporting it and testing it. Unfortunately, corner cases like this may
sometimes pass through the tests.

Dann, do you still have your samba server ready to try to reproduce this
problem ? Also, there are very suspect lines right there in the patch :

@@ -505,8 +510,13 @@
mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
 
-   mnt->flags = (oldmnt->file_mode >> 9);
+   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
+   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
+   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}


See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
expected thing like this but I wonder if the initial intent was exactly this.
Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
what I say is stupid, but it's just a guess.

Santiago, if you feel brave enough to try completely untested code, I
would suggest to try this change :

} else {
-   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
+   mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;


Also, please try making symlinks to directories to see how they behave.

Thanks in advance,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Santiago Garcia Mantinan
Hi!

I have discovered a problem with the changes applied to smbfs in 2.4.34 and
in the security backports like last Debian's 2.4 kernel update these changes
seem to be made to solve CVE-2006-5871 and they have broken symbolic links
and changed the way that special files (like devices) are seen.

For example:
Before: symbolic links were seen as that, symbolic links an thus if you tried
to open the file the link was followed and you ended up reading the
destination file
Now: symbolic links are seen as normal files (at least with a ls) but their
length (N) is the length of the symbolic link, if you read it, you'll get the
first N characters of the destination file. For example, on my filesystem
bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
get ELF (this is, the first 4 characters of the bash program, first one
being a DEL).

Another example:
Before: if you did a ls of a device file, like dev/zero you could see it as
a device, if you tried opening it, it wouldn't work, but if you did a cp -a
of that file to a local filesystem the result was a working zero device.
Now: the devices are seen as normal files with a length of 0 bytes.

Seems to me like a mask is erasing some mode bits that shouldn't be erased.

I have carried my tests on a Debian Sarge machine always mounting the share
using: smbmount //server/share /mnt without any other options. The tests
were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
samba 3.0.23d and I have experienced the same behaviour with samba's
unix extensions = yes and unix extensions = no.

I don't know what else to add, if you need any more info or want me to do
any tests just ask for it.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Santiago Garcia Mantinan
Hi!

I have discovered a problem with the changes applied to smbfs in 2.4.34 and
in the security backports like last Debian's 2.4 kernel update these changes
seem to be made to solve CVE-2006-5871 and they have broken symbolic links
and changed the way that special files (like devices) are seen.

For example:
Before: symbolic links were seen as that, symbolic links an thus if you tried
to open the file the link was followed and you ended up reading the
destination file
Now: symbolic links are seen as normal files (at least with a ls) but their
length (N) is the length of the symbolic link, if you read it, you'll get the
first N characters of the destination file. For example, on my filesystem
bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
get ELF (this is, the first 4 characters of the bash program, first one
being a DEL).

Another example:
Before: if you did a ls of a device file, like dev/zero you could see it as
a device, if you tried opening it, it wouldn't work, but if you did a cp -a
of that file to a local filesystem the result was a working zero device.
Now: the devices are seen as normal files with a length of 0 bytes.

Seems to me like a mask is erasing some mode bits that shouldn't be erased.

I have carried my tests on a Debian Sarge machine always mounting the share
using: smbmount //server/share /mnt without any other options. The tests
were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
samba 3.0.23d and I have experienced the same behaviour with samba's
unix extensions = yes and unix extensions = no.

I don't know what else to add, if you need any more info or want me to do
any tests just ask for it.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Willy Tarreau
Hello Santiago,

On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
 Hi!
 
 I have discovered a problem with the changes applied to smbfs in 2.4.34 and
 in the security backports like last Debian's 2.4 kernel update these changes
 seem to be made to solve CVE-2006-5871 and they have broken symbolic links
 and changed the way that special files (like devices) are seen.
 
 For example:
 Before: symbolic links were seen as that, symbolic links an thus if you tried
 to open the file the link was followed and you ended up reading the
 destination file
 Now: symbolic links are seen as normal files (at least with a ls) but their
 length (N) is the length of the symbolic link, if you read it, you'll get the
 first N characters of the destination file. For example, on my filesystem
 bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
 get ELF (this is, the first 4 characters of the bash program, first one
 being a DEL).
 
 Another example:
 Before: if you did a ls of a device file, like dev/zero you could see it as
 a device, if you tried opening it, it wouldn't work, but if you did a cp -a
 of that file to a local filesystem the result was a working zero device.
 Now: the devices are seen as normal files with a length of 0 bytes.
 
 Seems to me like a mask is erasing some mode bits that shouldn't be erased.
 
 I have carried my tests on a Debian Sarge machine always mounting the share
 using: smbmount //server/share /mnt without any other options. The tests
 were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
 Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
 samba 3.0.23d and I have experienced the same behaviour with samba's
 unix extensions = yes and unix extensions = no.
 
 I don't know what else to add, if you need any more info or want me to do
 any tests just ask for it.

Well, there is not much to add there. Thanks very much for all your tests.
This problem was not easy to fix, and Dann Frazier did a careful job at
backporting it and testing it. Unfortunately, corner cases like this may
sometimes pass through the tests.

Dann, do you still have your samba server ready to try to reproduce this
problem ? Also, there are very suspect lines right there in the patch :

@@ -505,8 +510,13 @@
mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
 
-   mnt-flags = (oldmnt-file_mode  9);
+   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
+   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
} else {
+   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG;
+   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;
}


See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
expected thing like this but I wonder if the initial intent was exactly this.
Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
what I say is stupid, but it's just a guess.

Santiago, if you feel brave enough to try completely untested code, I
would suggest to try this change :

} else {
-   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFREG;
-   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-   S_IROTH | S_IXOTH | S_IFDIR;
+   mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
+   mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+   S_IROTH | S_IXOTH | S_IFDIR;
if (parse_options(mnt, raw_data))
goto out_bad_option;


Also, please try making symlinks to directories to see how they behave.

Thanks in advance,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: problems with latest smbfs changes on 2.4.34 and security backports

2007-01-17 Thread Willy Tarreau
Hi Grant !

On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
(...)
  } else {
 -mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -S_IROTH | S_IXOTH | S_IFREG;
 -mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -S_IROTH | S_IXOTH | S_IFDIR;
 +mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
 +mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +S_IROTH | S_IXOTH | S_IFDIR;
  if (parse_options(mnt, raw_data))
  goto out_bad_option;
 
 I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
 to directories seen as target, nor can they be created (Operation not 
 permitted...)

Thanks very much Grant for the test. Could you try a symlink to a file ?
And while we're at it, would you like to try to add |S_IFLNK to
mnt-dir_mode ? If my suggestion was stupid, at least let's test it to
full extent ;-)

I had another idea looking at the code but since I really don't know it,
I would not like to propose random changes till this magically works. I'd
wait for Dann who understood the code.

Best regards,
Willy

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/