On Fri, 30 Aug 2013 06:43:36 +0200 Lionel Cons wrote:
> On 30 August 2013 06:36, Lionel Cons <[email protected]> wrote:
> > On 29 August 2013 19:45, Glenn Fowler <[email protected]> wrote:
> >> 13-08-25 path/pathcanon.c: finalize //@// extended/hidden attribute
> >> namespace *for testing*
> >
> > Didn't we had the discussion that this is inherently unsafe?
> >
> > If you build a path using variables from different sources you sooner
> > or later have leading or trailing slashes coming from many sources,
> > let or it users or config files, and no one sanitises paths. Not even
> > the Solaris or Linux kernels do that for system messages.
> >
> > For example:
> > PATH1='/var/run/'
> > CONFIGDIR='appconfig/'
> > LOCK='/@/' # use leading and trailing / to force @ being a directory
> > SUBLOCKFILE='/run1982'
> >
> > ${PATH1}/${CONFIGDIR}/${LOCK}/${SUBLOCKFILE} will then be
> > /var/run//appconfig///@///run1982
> >
> > Quick grep over /var/log/messages with grep -F '///' /var/log/messages
> > | wc -l returns 419
> >
> > Please rip that out. It'll never pass *any* security code review.
> Coworker just chatted me this alternative:
> > 1.better would be to use /dev/file@xattr/filepath to open the attribute
> > directory
> > and use /dev/fd/$fd/attr to access the files. there are so many ways people
> > can shoot themselves already in a shell and Glenn just handed them a
> > gun with the barrel pointing towards the face of the user
> > [..]
good point
I actually have most of that working and just need an explanation for
cd -@ regular-file
cd ..
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
