Bug 6593 - trans2 call info level SMB_INFO_STANDARD must be removed.
Summary: trans2 call info level SMB_INFO_STANDARD must be removed.
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.4.0
Hardware: Other Linux
: P3 regression
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-30 18:14 UTC by Jeremy Allison
Modified: 2011-03-17 22:33 UTC (History)
0 users

See Also:

Attachments
git-am style patch. (2.03 KB, patch)
2009-07-30 18:17 UTC, Jeremy Allison 		no flags Details
Correct patch for 3.4.1. (1.05 KB, text/x-diff)
2009-08-06 15:24 UTC, Jeremy Allison 		vl: review+
Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2009-07-30 18:14:09 UTC 
This is not a valid trans2 'set' call, also the implementation could read more pdata than sent (potential crash bug). Marking private.
Jeremy.
Comment 1 Jeremy Allison 2009-07-30 18:17:25 UTC 
Created attachment 4491 [details]
git-am style patch.

Fix (just remove this call). Volker please review and re-assign to Karolin.
Jeremy.
Comment 2 Volker Lendecke 2009-08-03 02:44:00 UTC 
Do we have a torture test for this?

Volker
Comment 3 Jeremy Allison 2009-08-05 19:27:58 UTC 
I thought this was covered by RAW-SFILEINFO in s4 torture ?
Jeremy.
Comment 4 Volker Lendecke 2009-08-06 04:22:42 UTC 
Hmmm. Looking at source4/torture/raw/setfileinfo.c:230 I get the impression that RAW-SFILEINFO believes that setting SMB_INFO_STANDARD must be allowed. Is there anything I'm getting wrong here?

Volker
Comment 5 Jeremy Allison 2009-08-06 13:19:31 UTC 
Crap - you are correct ! You can use the 12-byte dos dates here.
I'll fix that in master asap and prepare a patch for 3.4.1 and before.
Jeremy.
Comment 6 Jeremy Allison 2009-08-06 15:24:39 UTC 
Created attachment 4523 [details]
Correct patch for 3.4.1.

Correct patch (reads using srv_make_unix_date2()). Volker please review.
Jeremy.
Comment 7 Volker Lendecke 2009-08-10 05:26:27 UTC 
Hmmmm. To be honest, I never really understood the different time stamp formats we have on the wire. What is the time format that interpret_long_date() looks at, and what is the one srv_make_unix_date2() uses? And, how would I test this patch?

I'm surprised that such a basic function is wrong right now, that's why I am looking a bit closer. Sorry for that.

Volker
Comment 8 Jeremy Allison 2009-08-10 11:51:06 UTC 
No problem, thanks for looking.

The "new" time formats are the 8 byte NTTIME on the wire. The "old" time format is 4 bytes, like a UNIX time but in localtime, not GMT.

Look at this code for SET_FILE_INFO_STANDARD in current v3-3-test.

        /* access time */
        ts[0] = convert_time_t_to_timespec(srv_make_unix_date2(pdata+l1_fdateLastAccess));
        /* write time */
        ts[1] = convert_time_t_to_timespec(srv_make_unix_date2(pdata+l1_fdateLastWrite));

You can follow the logic through srv_make_unix_date2() -> make_unix_date2() -> make_unix_date().

As far as I can tell Windows doesn't ever use this infolevel for set, but it accepts it, so we have to :-(. The current code in v3-4-test is obviously incorrect (check size != read size).

The test is in RAW-SETFILEINFO torture/raw/setfileinfo.c:226 which we don't pass currently, so that's why this got left unfixed I think.

Jeremy.
Comment 9 Volker Lendecke 2009-08-11 01:16:44 UTC 
Comment on attachment 4523 [details]
Correct patch for 3.4.1.

Ok, that's how we got away with it. If Windows never uses it.... :-)

Thanks for the explanation!

Volker
Comment 10 Karolin Seeger 2009-08-12 09:29:44 UTC 
Pushed to v3-4-test.
Closing out bug report.

Thanks!