Linux wins on security in survey of 6,000+ software developers [LWN.net]

Linux wins on security in survey of 6,000+ software developers

Posted Apr 12, 2005 19:44 UTC (Tue) by hppnq (guest, #14462)
In reply to: Linux wins on security in survey of 6,000+ software developers by jwb
Parent article: Linux wins on security in survey of 6,000+ software developers

Strange reasoning, that would apply to any exploit ever published.

Judging from my own experience I'd say that most sysadmins -- and, more importantly, management -- I have met haven't got the faintest clue about security anyway. I have seen horrific stuff you wouldn't believe, at big, big companies.

But then, I am in a bad mood today, having had to deal with this very problem all day.

to post comments

Clueful?

Posted Apr 14, 2005 8:44 UTC (Thu) by shane (subscriber, #3335) [Link] (4 responses)

Most sysadmins and developers I know are superstitious. By this I mean that they don't want to understand the reason why things are, but rather just get them to work.

While this makes some sense from an engineering standpoint, I still cringe when I see people typing "sync; sync".

Clueful?

Posted Apr 14, 2005 14:59 UTC (Thu) by utidjian (guest, #444) [Link] (3 responses)

I am an adittedly superstitious sysadmin; and I want to know why you would cringe when you see someone type sync; sync ? Would it make you cringe less if they typed sync&& sync ? If so, why?

-DU-...etc...

Clueful?

Posted Apr 14, 2005 16:29 UTC (Thu) by jwb (guest, #15467) [Link] (2 responses)

I thought his point was, the second sync has no value. At least I hope that's his point.

Clueful?

Posted Apr 14, 2005 19:25 UTC (Thu) by roelofs (guest, #2599) [Link] (1 responses)

I thought his point was, the second sync has no value. At least I hope that's his point.

Tsk, newbies. ( ;-) )

Kernel-page article from three years ago:

How synchronous should sync be? Andrew Morton has posted a patch fixing a perceived problem with the sync() system call: as long as processes keep generating data, sync() will keep flushing it to disk. The result is that a sync command can take a long time to execute - as in several minutes. Andrew's patch changes sync() to just ensure that all data to be written when the call is made gets out - buffers generated thereafter may not be written immediately.
This patch, of course, changes a fundamental assumption made by many who use sync - that, upon completion, all data has been written to disk. In fact, according to the Single Unix Standard, this behavior is permissible: "The writing, although scheduled, is not necessarily complete upon return from sync()" It is, regardless, not the behavior that many expect.
There's no real consensus on what the proper behavior is. Unless Linus takes the patch, the current sync behavior will remain.

So I'm thinking the second and maybe even third sync has some value. :-)

(And I'm pretty sure I remember a followup, as well, in which further details were presented--for example, that there were already cases in which the "expected behavior" was not actually the real behavior--but I don't remember for sure. Maybe it's just my fevered imagination again...)

Greg

Clueful?

Posted Apr 14, 2005 21:37 UTC (Thu) by Zartan (guest, #23725) [Link]

More to the point, it's better to do:

# sync
# sync

typed in by hand, than either of the above. Why? Because the second or two that it takes to type the second sync helps compensate for the "scheduled but not necessarily written" aspect of POSIX sync(). Works on all *nixes.