On 09/11/15 14:54, Ngô Huy wrote: > Dear Padraig, > > 2015-11-09 18:20 GMT+07:00 Pádraig Brady <[email protected] > <mailto:[email protected]>>: > > On 09/11/15 08:30, Ngô Huy wrote: > > Dear guys, > > > > I had problem with mkdir and ls when I used command: > > > > mkdir "* /" && mkdir "* /etc" && ls. > > > > It only displayed *. > > Note as yet unreleased version of ls will use shell quoting > to give a less ambiguous output: > > $ ls > '* ' > > > But > > > > find . -type d -print > > > > display ./* /etc. > > > > If we have hidden directory and use xargs with find to execute some > command, it's security risk. Should we patch it's behavior ? > > I think you're worried about the '*' being expanded? > Or maybe the xargs splitting on the space. > In any case you can use `find ... -print0 | xargs -0` > to handle that. > > Not something that mkdir (coreutils) should be worried > about in any case. > > I see this, but when use mkdir "* /" && mkdir "* /etc", it shouldn't be / in > file name, right ?
I don't see the issue here. mkdir is just passing down to the mkdir syscall to create the "* /etc" dir, i.e. the 'etc' dir in the already created '* ' dir. > We try to avoid incident problem, I think we should limit file name's > character. That would have to be done at the kernel level. There have been proposals with POSIX to use a restricted character set for file names. thanks, Pádraig.
