CIFS extensions for UNIX
jn at it.swin.edu.au
Sat Feb 2 02:35:03 GMT 2002
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
> 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
>>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.
PS: You can get my latest smbfs patch from here
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
More information about the samba-technical