Forgot your password?

Comment: Re:My opinion on the matter. (Score 1) 810

by Gunstick (#47755513) Attached to: Choose Your Side On the Linux Divide

and this SMF may be coll and fancy, but it's a horrible headache for a "normal unix" sysadmin.
Why can't it just be simple files? Oh no, we need a frontend to dump in and out unreadable XML data.

Same goes qith AIX and it's internal database hiding stuff from the users.

So finally every unix and linux has it's own, incompatible "I want to do horrible registry like windows" hack just because it's cool and hip, but it's not useable.

Does systemd present a virtual filesystem where you can edit text files with vi and get the thing configured? That would be one idea with which I could still use my beloved broadcast sed commands to change configs on 100 servers.

Comment: Re:Old problem. Let's fix it. (Score 1) 215

by Gunstick (#47349343) Attached to: Exploiting Wildcards On Linux/Unix

you are not precise on one point

In unix world, this long known issue was only about the first filename. Typically with classig usage of tar, the first file is your archive, and all others are just filenames. unix/bsd treat them as filenames.

Now comes GNU getopt and "suddenly" decides that from now on it would be cool to have options anywhere on the command line. Result is that in GNU-world, tar is now vulnerable (and many many other commands) which had had no issue at all previously.

I would really like that getopt changes back to "if we see filenames, then consider being after --" or rather: stop parsing options if you find a parameter which does not match any option. That's the last one. Just stop there, do not continue. Leave the rest as it is.

Comment: Re:linux problem NOT unix problem! (Score 1) 215

by Gunstick (#47349211) Attached to: Exploiting Wildcards On Linux/Unix

the "first file in the list" problem is known to anyone doing unix since 30 years.
What's new here is that now the option can hide anywhere in the list.

Funny: in unix, the -file is lexicographically globbed onto first position (- comes before a, typically LANG=C)
in linux, you have some other oder... and it's first "a" then "-a" so the problem file does not come first. This would save one or the other exploit.... but getopt makes it so that the exploit works in any case.

Comment: Re:Sanitize crazyness (Score 1) 215

by Gunstick (#47349175) Attached to: Exploiting Wildcards On Linux/Unix

it's not the bash problem
the problem is that getopt gives tar that there is a parameter.... which is in fact a filename hidden somewhere deep in the file list.

tar cf archive.tar file1 file2 -v file3 # is verbose on linux, is NOT verbose on UNIX (complains about inexisting file "-v")

GNU is wrong, GNU broke the inherent security in options parsing by allowing options anywhere. GNU is insecure.

Comment: Re:Question... -- ? (Score 1) 215

by Gunstick (#47349111) Attached to: Exploiting Wildcards On Linux/Unix

> If the first file name starts with a dash, how do you know it's a file name?

here all the other poster's arguments are valid. The first file being a -file has always been a concern in the unix world and programmers worked around that.
But what's new with GNU, is that if you hid a command swithc in a long list of filenames, it won't be seen as a file but as a command switch. And that's where you shoot yourself in the foot.
On old unix system this will never kill you: rm /tmp/file1 /tmp/file2 *
On linux, you are ready for losing all in you current directory's subdirs (or any other trickery of the original post)

Comment: linux problem NOT unix problem! (Score 3, Interesting) 215

by Gunstick (#47332993) Attached to: Exploiting Wildcards On Linux/Unix

This is because the linux commands do not respect what the manual says:
man rm...

rm [OPTION]... FILE...

but in realitiy it's rather:

rm [OTION|FILE]...

whereas on other unix systems it works as expected, first the options, then the arguments
rm *
rm: DIR1 directory

rm *
rm: DIR1 directory

So screw the GNU tools, they mess things up for the "old unix sysadmins"

Here is a nice linux/unix trap:
y="rm z"
f=$x $y

So you expect f to contain: a rm z
not really...
z: No such file or directory
so the rm actually was executed

a=$x is an environment variable attribution, so $y becomes an executed command...
And that one works on any unix/linux
Recently patched in chkrootkit (CVE-2014-0476)

Comment: Re:Mr Fixit (Score 1) 582

by Gunstick (#46764943) Attached to: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

for years yes, but not for very long.
Especially professionals have a very long software cycle, still hanging around with redhat5 and other old stuff.
The bug was introduced in 1.01 and RH5 still runs 0.9.8
I have seen that a lot of times, bleeding edge may be cool, but not necessarily secure. Staying too far behind (into the non supported area) is not secure either.
So the "one release back" strategy is not bad. In this aspect debian stable is a bit too up to date.

Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.