Re: [patch] rc.d/tmp (silly mkdir usage)
diz_at_linuxpowered.com
Date: 08/02/05
- Previous message: Vasil Dimov: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- In reply to: Vasil Dimov: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Next in thread: Brooks Davis: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Brooks Davis: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Craig Boston: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Frank Mayhar: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 2 Aug 2005 11:47:19 -0500 (CDT) To: vd@datamax.bg
> On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote:
>> Howdy hackers,
>>
>> I'm sorry for the previous patch, so here is at least one item that
>> really
>> bugs me that isn't obfuscation. In short, I don't see any reason to fork
>> some process to simply "touch" a file (is a filesystem writable) when
>> built-in shell i/o does this:
>>
>> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005
>> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005
>> @@ -48,8 +48,8 @@
>> [Nn][Oo])
>> ;;
>> *)
>> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then
>> - rmdir /tmp/.diskless
>> + if ( > /tmp/.diskless 2> /dev/null); then
>> + rm /tmp/.diskless
>> else
>> if [ -h /tmp ]; then
>> echo "*** /tmp is a symlink to a non-writable
>> area!"
>>
>
> The thing you suggest is bloody insecure. Just imagine some baduser
> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed.
> I guess this is the reason why directory creation is used instead of
> file creation.
Well these notions have nothing todo with the way it works, but they are
interesting still. I would imagine a dir could be linked too if somebody
managed to insert a rc.d script in that was ordered sufficiently early
enough to do the evil tasks you are thinking about. Even if mktemp(1) were
available at this stage, I wouldn't use it here.
>
> I just wonder why a new shell is forked for this test. Simply
> if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then
> would do the same thing without forking a new shell that only executes
> /bin/mkdir
Let me be clear about this, the ONLY reason mkdir is used here is because
touch is under /usr somewhere which isn't even mounted at this point
(assuming /usr is mounted seperatly, as is the case on nfs diskless
systems). So we are left with what is availabile in /bin, /sbin, /rescue.
Therefore mkdir was used as a work-around. What I'm saying is this entire
thought process is overly-engineered when the shell can simply "touch" a
file with stdout or stderr. This is indeed the most minor of
optimizations.
>
> Even we can use
> if [ -d /tmp -a -w /tmp ] ; then
> or (which is equivalent)
> if [ -d /tmp ] && [ -w /tmp ] ; then
> and save external commands (mkdir) execution and directory
> creation/deletion at all.
>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Vasil Dimov: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- In reply to: Vasil Dimov: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Next in thread: Brooks Davis: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Brooks Davis: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Craig Boston: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Reply: Frank Mayhar: "Re: [patch] rc.d/tmp (silly mkdir usage)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
