Bug 6593 - trans2 call info level SMB_INFO_STANDARD must be removed.
trans2 call info level SMB_INFO_STANDARD must be removed.
Product: Samba 3.4
Classification: Unclassified
Component: File services
Other Linux
: P3 regression
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-07-30 18:14 UTC by Jeremy Allison
Modified: 2011-03-17 22:33 UTC (History)
0 users

See Also:

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+

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.
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.
Comment 2 Volker Lendecke 2009-08-03 02:44:00 UTC
Do we have a torture test for this?

Comment 3 Jeremy Allison 2009-08-05 19:27:58 UTC
I thought this was covered by RAW-SFILEINFO in s4 torture ?
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?

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.
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.
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.

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.


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!

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