1 /* 2 * CDDL HEADER START 3 * 4 * The contents of this file are subject to the terms of the 5 * Common Development and Distribution License (the "License"). 6 * You may not use this file except in compliance with the License. 7 * 8 * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 9 * or http://www.opensolaris.org/os/licensing. 10 * See the License for the specific language governing permissions 11 * and limitations under the License. 12 * 13 * When distributing Covered Code, include this CDDL HEADER in each 14 * file and include the License file at usr/src/OPENSOLARIS.LICENSE. 15 * If applicable, add the following below this CDDL HEADER, with the 16 * fields enclosed by brackets "[]" replaced with your own identifying 17 * information: Portions Copyright [yyyy] [name of copyright owner] 18 * 19 * CDDL HEADER END 20 */ 21 /* 22 * Copyright 2008 Sun Microsystems, Inc. All rights reserved. 23 * Use is subject to license terms. 24 */ 25 26 #pragma ident "%Z%%M% %I% %E% SMI" 27 28 #include <smbsrv/smb_incl.h> 29 30 31 /* 32 * smb_com_find 33 * 34 * Request Format: (same as core Search Protocol - "Find First" form) 35 * 36 * Client Request Description 37 * ================================== ================================= 38 * 39 * BYTE smb_wct; value = 2 40 * WORD smb_count; max number of entries to find 41 * WORD smb_attr; search attribute 42 * WORD smb_bcc; minimum value = 5 43 * BYTE smb_ident1; ASCII (04) 44 * BYTE smb_pathname[]; filename (may contain global characters) 45 * BYTE smb_ident2; Variable Block (05) 46 * WORD smb_keylen; resume key length (zero if "Find First") 47 * BYTE smb_resumekey[*]; "Find Next" key, * = value of smb_keylen 48 * 49 * Response Format: (same as core Search Protocol) 50 * 51 * Server Response Description 52 * ================================== ================================= 53 * BYTE smb_wct; value = 1 54 * WORD smb_count; number of entries found 55 * WORD smb_bcc; minimum value = 3 56 * BYTE smb_ident; Variable Block (05) 57 * WORD smb_datalen; data length 58 * BYTE smb_data[*]; directory entries 59 * 60 * Directory Information Entry (dir_info) Format: (same as core Search Protocol) 61 * 62 * BYTE find_buf_reserved[21]; reserved (resume_key) 63 * BYTE find_buf_attr; attribute 64 * WORD find_buf_time; modification time (hhhhh mmmmmm xxxxx) 65 * where 'xxxxx' is in 2 second increments 66 * WORD find_buf_date; modification date (yyyyyyy mmmm ddddd) 67 * DWORD find_buf_size; file size 68 * STRING find_buf_pname[13]; file name -- ASCII (null terminated) 69 * 70 * The resume_key has the following format: 71 * 72 * BYTE sr_res; reserved: 73 * bit 7 - reserved for consumer use 74 * bit 5,6 - reserved for system use 75 * (must be preserved) 76 * bits 0-4 - reserved for server 77 * (must be preserved) 78 * BYTE sr_name[11]; pathname sought. 79 * Format: 1-8 character file name, 80 * left justified 0-3 character extension, 81 * BYTE sr_findid[1]; uniquely identifies find through 82 * find_close 83 * BYTE sr_server[4]; available for server use 84 * (must be non-zero) 85 * BYTE sr_res[4]; reserved for consumer use 86 * 87 * Service: 88 * 89 * The Find protocol finds the directory entry or group of entries matching the 90 * specified file pathname. The filename portion of the pathname may contain 91 * global (wild card) characters. 92 * 93 * The Find protocol is used to match the find OS/2 system call. The protocols 94 * "Find", "Find_Unique" and "Find_Close" are methods of reading (or searching) 95 * a directory. These protocols may be used in place of the core "Search" 96 * protocol when LANMAN 1.0 dialect has been negotiated. There may be cases 97 * where the Search protocol will still be used. 98 * 99 * The format of the Find protocol is the same as the core "Search" protocol. 100 * The difference is that the directory is logically Opened with a Find protocol 101 * and logically closed with the Find Close protocol. This allows the Server to 102 * make better use of its resources. Search buffers are thus held (allowing 103 * search resumption via presenting a "resume_key") until a Find Close protocol 104 * is received. The sr_findid field of each resume key is a unique identifier 105 * (within the session) of the search from "Find" through "Find close". Thus if 106 * the consumer does "Find ahead", any find buffers containing resume keys with 107 * the matching find id may be released when the Find Close is requested. 108 * 109 * As is true of a failing open, if a Find request (Find "first" request where 110 * resume_key is null) fails (no entries are found), no find close protocol is 111 * expected. 112 * 113 * If no global characters are present, a "Find Unique" protocol should be used 114 * (only one entry is expected and find close need not be sent). 115 * 116 * The file path name in the request specifies the file to be sought. The 117 * attribute field indicates the attributes that the file must have. If the 118 * attribute is zero then only normal files are returned. If the system file, 119 * hidden or directory attributes are specified then the search is inclusive -- 120 * both the specified type(s) of files and normal files are returned. If the 121 * volume label attribute is specified then the search is exclusive, and only 122 * the volume label entry is returned 123 * 124 * The max-count field specifies the number of directory entries to be returned. 125 * The response will contain zero or more directory entries as determined by the 126 * count-returned field. No more than max-count entries will be returned. Only 127 * entries that match the sought filename/attribute will be returned. 128 * 129 * The resume_key field must be null (length = 0) on the initial ("Find First") 130 * find request. Subsequent find requests intended to continue a search must 131 * contain the resume_key field extracted from the last directory entry of the 132 * previous response. The resume_key field is self-contained, for on calls 133 * containing a resume_key neither the attribute or pathname fields will be 134 * valid in the request. A find request will terminate when either the 135 * requested maximum number of entries that match the named file are found, or 136 * the end of directory is reached without the maximum number of matches being 137 * found. A response containing no entries indicates that no matching entries 138 * were found between the starting point of the search and the end of directory. 139 * 140 * There may be multiple matching entries in response to a single request as 141 * Find supports "wild cards" in the file name (last component of the pathname). 142 * "?" is the wild single characters, "*" or "null" will match any number of 143 * filename characters within a single part of the filename component. The 144 * filename is divided into two parts -- an eight character name and a three 145 * character extension. The name and extension are divided by a ".". 146 * 147 * If a filename part commences with one or more "?"s then exactly that number 148 * of characters will be matched by the Wild Cards, e.g., "??x" will equal "abx" 149 * but not "abcx" or "ax". When a filename part has trailing "?"s then it will 150 * match the specified number of characters or less, e.g., "x??" will match 151 * "xab", "xa" and "x", but not "xabc". If only "?"s are present in the filename 152 * part, then it is handled as for trailing "?"s "*" or "null" match entire 153 * pathname parts, thus "*.abc" or ".abc" will match any file with an extension 154 * of "abc". "*.*", "*" or "null" will match all files in a directory. 155 * 156 * Unprotected servers require the requester to have read permission on the 157 * subtree containing the directory searched (the share specifies read 158 * permission). 159 * 160 * Protected servers require the requester to have permission to search the 161 * specified directory. 162 * 163 * If a Find requests more data than can be placed in a message of the 164 * max-xmit-size for the TID specified, the server will return only the number 165 * of entries which will fit. 166 * 167 * The number of entries returned will be the minimum of: 168 * 1. The number of entries requested. 169 * 2. The number of (complete) entries that will fit in the negotiated SMB 170 * buffer. 171 * 3. The number of entries that match the requested name pattern and 172 * attributes. 173 * 174 * The error ERRnofiles set in smb_err field of the response header or a zero 175 * value in smb_count of the response indicates no matching entry was found. 176 * 177 * The resume search key returned along with each directory entry is a server 178 * defined key which when returned in the Find Next protocol, allows the 179 * directory search to be resumed at the directory entry fol lowing the one 180 * denoted by the resume search key. 181 * 182 * The date is in the following format: 183 * bits: 184 * 1 1 1 1 1 1 185 * 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 186 * y y y y y y y m m m m d d d d d 187 * where: 188 * y - bit of year 0-119 (1980-2099) 189 * m - bit of month 1-12 190 * d - bit of day 1-31 191 * 192 * The time is in the following format: 193 * bits: 194 * 1 1 1 1 1 1 195 * 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 196 * h h h h h m m m m m m x x x x x 197 * where: 198 * h - bit of hour (0-23) 199 * m - bit of minute (0-59) 200 * x - bit of 2 second increment 201 * 202 * Find may generate the following errors. 203 * ERRDOS/ERRnofiles 204 * ERRDOS/ERRbadpath 205 * ERRDOS/ERRnoaccess 206 * ERRDOS/ERRbadaccess 207 * ERRDOS/ERRbadshare 208 * ERRSRV/ERRerror 209 * ERRSRV/ERRaccess 210 * ERRSRV/ERRinvnid 211 */ 212 int 213 smb_com_find(struct smb_request *sr) 214 { 215 int rc; 216 unsigned short sattr, count, maxcount; 217 char *path; 218 char filename[14]; 219 uint32_t cookie; 220 struct smb_node *node; 221 unsigned char type; 222 unsigned short key_len; 223 smb_odir_context_t *pc; 224 225 if (smbsr_decode_vwv(sr, "ww", &maxcount, &sattr) != 0) { 226 smbsr_decode_error(sr); 227 /* NOTREACHED */ 228 } 229 230 if ((smbsr_decode_data(sr, "%Abw", sr, &path, &type, &key_len) != 0) || 231 (type != 0x05)) { 232 smbsr_decode_error(sr); 233 /* NOTREACHED */ 234 } 235 236 if (key_len == 0) { /* begin search */ 237 (void) smb_rdir_open(sr, path, sattr); 238 cookie = 0; 239 } else if (key_len == 21) { 240 sr->smb_sid = 0; 241 if (smb_decode_mbc(&sr->smb_data, SMB_RESUME_KEY_FMT, 242 filename, &sr->smb_sid, &cookie) != 0) { 243 /* We don't know which rdir to close */ 244 smbsr_decode_error(sr); 245 /* NOTREACHED */ 246 } 247 248 sr->sid_odir = smb_odir_lookup_by_sid(sr->tid_tree, 249 sr->smb_sid); 250 if (sr->sid_odir == NULL) { 251 smbsr_error(sr, NT_STATUS_INVALID_HANDLE, 252 ERRDOS, ERRbadfid); 253 /* NOTREACHED */ 254 } 255 256 cookie--; /* +1 when returned */ 257 } else { 258 /* We don't know which rdir to close */ 259 smbsr_decode_error(sr); 260 /* NOTREACHED */ 261 } 262 263 (void) smb_encode_mbc(&sr->reply, "bwwbw", 1, 0, VAR_BCC, 5, 0); 264 265 pc = MEM_ZALLOC("smb", sizeof (*pc)); 266 pc->dc_cookie = cookie; 267 count = 0; 268 node = (struct smb_node *)0; 269 rc = 0; 270 while (count < maxcount) { 271 if ((rc = smb_rdir_next(sr, &node, pc)) != 0) 272 break; 273 274 (void) smb_encode_mbc(&sr->reply, ".8c3cbl4.bYl13c", 275 pc->dc_name83, pc->dc_name83+9, sr->smb_sid, 276 pc->dc_cookie+1, pc->dc_dattr, 277 smb_gmt_to_local_time(pc->dc_attr.sa_vattr.va_mtime.tv_sec), 278 (int32_t)smb_node_get_size(node, &pc->dc_attr), 279 (*pc->dc_shortname) ? pc->dc_shortname : pc->dc_name); 280 smb_node_release(node); 281 node = (struct smb_node *)0; 282 count++; 283 } 284 MEM_FREE("smb", pc); 285 286 if ((rc != 0) && (rc != ENOENT)) { 287 /* returned error by smb_rdir_next() */ 288 smb_rdir_close(sr); 289 smbsr_errno(sr, rc); 290 /* NOTREACHED */ 291 } 292 293 if (count == 0) { 294 smb_rdir_close(sr); 295 smbsr_error(sr, 0, ERRDOS, ERRnofiles); 296 /* NOTREACHED */ 297 } 298 299 rc = (MBC_LENGTH(&sr->reply) - sr->cur_reply_offset) - 8; 300 if (smb_poke_mbc(&sr->reply, sr->cur_reply_offset, 301 "bwwbw", 1, count, rc+3, 5, rc) < 0) { 302 smb_rdir_close(sr); 303 smbsr_encode_error(sr); 304 /* NOTREACHED */ 305 } 306 307 return (SDRC_NORMAL_REPLY); 308 } 309 310 /* 311 * smb_com_find_close 312 * 313 * Request Format: (same as core Search Protocol - "Find Next" form) 314 * 315 * Client Request Description 316 * ================================== ================================= 317 * 318 * BYTE smb_wct; value = 2 319 * WORD smb_count; max number of entries to find 320 * WORD smb_attr; search attribute 321 * WORD smb_bcc; minimum value = 5 322 * BYTE smb_ident1; ASCII (04) 323 * BYTE smb_pathname[]; null (may contain only null) 324 * BYTE smb_ident2; Variable Block (05) 325 * WORD smb_keylen; resume (close) key length 326 * (may not be zero) 327 * BYTE smb_resumekey[*]; "Find Close" key 328 * (* = value of smb_keylen) 329 * 330 * Response Format: (same format as core Search Protocol) 331 * 332 * Server Response Description 333 * ================================== ================================= 334 * 335 * BYTE smb_wct; value = 1 336 * WORD smb_reserved; reserved 337 * WORD smb_bcc; value = 3 338 * BYTE smb_ident; Variable Block (05) 339 * WORD smb_datalen; data length (value = 0) 340 * 341 * The resume_key (or close key) has the following format: 342 * 343 * BYTE sr_res; reserved: 344 * bit 7 - reserved for consumer use 345 * bit 5,6 - reserved for system use 346 * (must be preserved) 347 * bits 0-4 - rsvd for server 348 * (must be preserved by consumer) 349 * BYTE sr_name[11]; pathname sought. 350 * Format: 1-8 character file name, 351 * left justified 0-3 character extension, 352 * left justified (in last 3 chars) 353 * BYTE sr_findid[1]; uniquely identifies find 354 * through find_close 355 * BYTE sr_server[4]; available for server use 356 * (must be non-zero) 357 * BYTE sr_res[4]; reserved for consumer use 358 * 359 * Service: 360 * 361 * The Find_Close protocol closes the association between a Find id 362 * returned (in the resume_key) by the Find protocol and the directory 363 * search. 364 * 365 * Whereas the First Find protocol logically opens the directory, 366 * subsequent find protocols presenting a resume_key further "read" the 367 * directory, the Find Close protocol "closes" the directory allowing the 368 * server to free any resources held in support of the directory search. 369 * 370 * The Find Close protocol is used to match the find Close OS/2 371 * system call. The protocols "Find", "Find Unique" and "Find Close" are 372 * methods of reading (or searching) a directory. These protocols may 373 * be used in place of the core "Search" protocol when LANMAN 1.0 dialect has 374 * been negotiated. There may be cases where the Search protocol will still be 375 * used. 376 * 377 * Although only the find id portion the resume key should be 378 * required to identify the search being ter minated, the entire 379 * resume_key as returned in the previous Find, either a "Find First" or "Find 380 * Next" is sent to the server in this protocol. 381 * 382 * Find Close may generate the following errors: 383 * 384 * ERRDOS/ERRbadfid 385 * ERRSRV/ERRerror 386 * ERRSRV/ERRinvnid 387 */ 388 int 389 smb_com_find_close(struct smb_request *sr) 390 { 391 unsigned short sattr, maxcount; 392 char *path; 393 char filename[14]; 394 uint32_t cookie; 395 unsigned char type; 396 unsigned short key_len; 397 int rc; 398 399 if (smbsr_decode_vwv(sr, "ww", &maxcount, &sattr) != 0) { 400 smbsr_decode_error(sr); 401 /* NOTREACHED */ 402 } 403 404 rc = smbsr_decode_data(sr, "%Abw", sr, &path, &type, &key_len); 405 if ((rc != 0) || (type != 0x05)) { 406 smbsr_decode_error(sr); 407 /* NOTREACHED */ 408 } 409 410 if (key_len == 0) { /* begin search */ 411 smbsr_error(sr, NT_STATUS_INVALID_HANDLE, ERRDOS, ERRbadfid); 412 /* NOTREACHED */ 413 } 414 415 if (key_len == 21) { 416 sr->smb_sid = 0; 417 if (smb_decode_mbc(&sr->smb_data, SMB_RESUME_KEY_FMT, 418 filename, &sr->smb_sid, &cookie) != 0) { 419 smbsr_decode_error(sr); 420 /* NOTREACHED */ 421 } 422 423 sr->sid_odir = smb_odir_lookup_by_sid(sr->tid_tree, 424 sr->smb_sid); 425 if (sr->sid_odir == NULL) { 426 smbsr_error(sr, NT_STATUS_INVALID_HANDLE, 427 ERRDOS, ERRbadfid); 428 /* NOTREACHED */ 429 } 430 431 cookie--; /* +1 when returned */ 432 } else { 433 smbsr_decode_error(sr); 434 /* NOTREACHED */ 435 } 436 437 smb_rdir_close(sr); 438 smbsr_encode_result(sr, 1, 3, "bwwbw", 1, 0, 3, 5, 0); 439 return (SDRC_NORMAL_REPLY); 440 } 441