CIFS extensions for UNIX

[John Newbigin]

Jeremy Allison wrote:

> On Fri, Feb 01, 2002 at 03:21:21PM +1100, John Newbigin wrote:
> 
>>I have implemented follow_link which makes symlinks work properly on the 
>>client but it highligts a problem with SMB_QUERY_FILE_UNIX_BASIC.
>>
>>There needs to be a version which always does an lstat 
>>(SMB_QUERY_FILE_UNIX_LINK_BASIC?) (does_this_name_look_to_long?).  This 
>>needs to be the same as SMB_QUERY_FILE_UNIX_BASIC in all respects except 
>>that it does an lstat.
>>
>>There are also other stat v lstat problems with the current samba code. 
>>SMB_QUERY_FILE_UNIX_LINK currently does no do an lstat.
>>
>>In trans2.c call_trans2qfilepathinfo() there is some code which is 
>>perhaps meant to address this but I can't see how/what it is attempting 
>>to do:
>>
> 
> Yes this was broken. I've (hopefully) fixed this in SAMBA_2_2 CVS
> today. Please check out and test asap. I won't hold the release
> for this.

This appears to work now :)


> 
> 
>>At any rate, the server needs to allow the client do request a stat or 
>>an lstat when it does a query.
>>
> 
> The new code always does a lstat for UNIX extensions.


Would a client ever want to do a stat?  Not if links are followed on the 
client side but smbclient for example would not want to do this.  It 
then would want to use a stat.  Also in directory listings it may not 
want to know about links.

There are a number of constants SMB_xxx_NO_CHANGE.  These are all 
0xFFFFFFFF, a 32 bit number even though they are for a 64 bit data type.

Should they all then be 0xFFFFFFFFFFFFFFFF?

Also, what about a SMB_SIZE_NO_CHANGE?  I can send a new patch if you want.

As for SMB_TIME_NO_CHANGE. 0 and -1 are treated as no change but they 
are used after interpret_long_date() has converted the date. using 
0xFFFFFFFFFFFFFFFF would remain consistant with the other NO_CHANGE 
constants and can be checked before the conversion (or as part of the 
conversion).


> 
> 
>>Another issue relating to links is that samba appears to not want to 
>>create dangling symlinks.  If symlinks are for the clients to resolve 
>>then this will prevent the creation of symlinks.  This needs to be 
>>addressed.  If it is a security issue then a config option to turn it on 
>>and off is probably required.
>>
> 
> Yes this is a security issue - allowing dangling symlinks means
> clients that don't resolve symlinks could open any file on the
> system. A config option has already been discussed but I wasn't
> going to make 2.2.3 wait for it.

The server can still check to make sure that the link is within the 
share, and the users permissions are still checked on the target.

I don't think any of these issues need to be addressed before 2.2.3.  I 
assume that these extensions are still going to be an experimental 
feature in 2.2.3.

Another issue which will require some long term though is case 
sensitivity.  I have come across a directory with a file called 
"INSTALL" and a sub directory called "install".  Accessing either of 
these files caused errors to be reported.

John.

PS:  You can get my latest smbfs patch from here
http://uranus.it.swin.edu.au/~jn/linux/smbfs/smbfs.diff2

Make sure that your smbd checks for SMB_SIZE_NO_CHANGE before you try 
changing any file properties or you will end up with some big files.

PPS: Make sure that SMB_SIZE_NO_CHANGE is the same for the client and 
the server.


> 
> Jeremy.
> 
> 
> 
>