On 08/04/2012 04:57 PM, Dave Reisner wrote: > On Sat, Aug 04, 2012 at 04:42:10PM +0100, Pádraig Brady wrote: >> There was a recent change in df in coreutils to sanitize output of paths: >> >> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3ed70fd >> >> The essential issue fixed there is that control chars in a path will be >> converted to '?' (this works in all locales), and doing so will mean >> '\n' for example is not output. You could even consider this a potential >> security improvement so that arbitrary users couldn't influence the >> output of these commands for all users. >> >> I suggest using the simple inplace replacement function from above. > > Why replace with a bogus character when you could instead use an octal > or hex escape? Wouldn't this still address the underlying problem? > Munging the content of a string could break a script consuming the > output with no way for the script to recover. Yes true. I suppose you could use octal escapes, so 0x00 -> 0x1F are mapped to \000 -> \037 and '\' is mapped to \134 That's more invasive though. For df for now at least it was thought that requiring unambiguous output for these names was overkill. The names were adjusted just so as to avoid processing issues for other sanely named items. Also related is the issue of non printable characters. For example if you view the unicode line separator char (\u2028) in certain places (like a pango editor like gedit for example) it will appear as a normal new line. It might be appropriate to replace or escape all non printable chars. That's complicated though (mbsalign in util-linux already does this to some extent). So you could have complex mappings, but I was thinking at least for these utils a simple method is appropriate to avoid the immediate issue. cheers, Pádraig. -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
