[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    Re: security(8) setuid checks and space character in file name
From:       Ingo Schwarze <schwarze () usta ! de>
Date:       2010-12-29 23:21:03
Message-ID: 20101229232103.GB1911 () iris ! usta ! de
[Download RAW message or body]

Ingo Schwarze wrote on Wed, Dec 29, 2010 at 08:37:16PM +0100:
> MERIGHI Marcus wrote on Wed, Dec 29, 2010 at 07:43:08PM +0100:
 
>> security(8) reports 
>> ``/home/XXX/Daten/Edv/macs/macs-home/Library/Application''
>> as ``Setuid additions:'' where the real file name is
>> ``/home/XXX/Daten/Edv/macs/macs-home/Library/Application Support/\
>> ProxyOnOff/proxyOnOffTool''
>> 
>> I have found the source of the wrong file name report to be in line 437
>> of /etc/security:
>> ``egrep -av '^[bc]' $LIST | join -o $FIELDS2 -110 -210 -v2 \
>> /dev/null - > $TMP1'',
>> 
>> with join having space (and tab) characters as field separators and thus
>> ignoring after first space characters found in field 10.

> Hmm, i consider that a bug in security(8).
 
>> No quick fix that comes to my mind, using -t to join(1) would help only
>> if the output of ls(1) in line 430 would be changed to not contain space
>> characters as output separators. 

> That idea is not bad.
> Maybe, one could use sed(1) or awk(1) to translate the first ten spaces
> to null bytes before the join, then translate them back before output,
> if needed.  Or something similar.

That didn't work.  It turned out the null byte can only be used as
a delimiter by utilities explicitly supporting it (like xargs(1)),
not by random utilities like join(1).  And any other replacement
runs a risk to be contained in file names as well.

> I should probably have a closer look.

I have posted a patch using another approach to tech@:

  http://marc.info/?l=openbsd-tech&m=129366420512212

It's not pretty, though.

[prev in list] [next in list] [prev in thread] [next in thread]