[EMAIL PROTECTED] wrote:
> On Dec 11, 2007 12:30 AM, Porkchop <[EMAIL PROTECTED]> wrote:
>
>> Have an open mind. Just that one can't think of a situation in which
>> this would be a good idea doesn't mean there is no case in which this is
>> a good idea.
>>
>
> Ok, I'm trying but I really can't imagine any good reason to execute a
> shell script directly fetched over HTTP. Not on a private lan, not
> anywhere. HTTP is completely unencrypted, and it's easily spoofable.
> If you can live with that, so be it..
>
>
First off, I really appreciate everyone's responses. :-) Man, you guys
are making me work for this one! LOL!
Regarding this tangent, I think Porkchop (and others) are right,
shouldn't we consider the significance of the potential threat ?
Wouldn't you trust an Intranet script from a trusted source in response
to a specific issue? Here's some examples; end user breaks yum, end
user breaks VPN software, end user breaks software and is unable to fix
it. Now consider that they are in another country.
> NFS is our friend. :-)
>
Have to admit, not a huge fan. To me it requires a few ports/services,
can get gummed up on some routers, prone to vulnerabilities, not always
easy to deploy, not great with low bandwidth connections, and not always
particularly easy to debug.
[EMAIL PROTECTED] ~]# netstat -ntlp | wc
17 120 1786
[EMAIL PROTECTED] ~]# service nfs start
[EMAIL PROTECTED] ~]# netstat -ntlp | wc
21 148 2222
>> Yes, I realize you assumed he was using a public internet site he has no
>> control over rather than an intranet server. But he didn't tell us that.
>>
>
> Again, HTTP is so easily spoofable that even people that ask for help
> about bash can do it. If he's on an intranet so large as to require
> automated installation solutions, then there's a fairly good chance, I
> think, that there are other people on the network besides him. The
> moment you add another person into the equation, the network should
> now be assumed compromised; I may be being a bit pessimistic here, but
> we're talking about "Administrator" priviledges.
>
>
Probably the best response to the "security issue" would be to just use
HTTPS (ie. curl https://host/file.sh). Users will have to trust scripts
anyway, there is little risk.
>> Its perfectly legitimate to warn him "this may not be what you want to
>> do", but there's no need to repeatedly flame him when you may not know
>> exactly what is going on.
>> -porkchop
>>
>
> Ok, so noted. Original poster, please please read the manual page for
> curl and if that is too much time (actually that manual is really
> big..) skip down to the -s/--silent parameter (I would also request
> that you check out the -n/--netrc option for nice net authentication
> support in curl just in case the whole password thing you originally
> asked about is in regards to authorization attempts to obtain
> root_me.sh). Your original post showed the progress meter which was
> seemingly interfering in your subsequent commands, which is probably
> not what you want or expected.
>
>
Thanks for the help. :-) sadly the options didn't change anything , I
think it has nothing to do with curl and really is an issue with su
being piped. Hoping that someone knew some straight forward trick to
get around this, anyway. Thanks again. :-)
[EMAIL PROTECTED] ~]$ su - | bash
Password:
[EMAIL PROTECTED] ~]$ echo "su -" | bash
standard in must be a tty
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) MHVLS Auditorium
Dec 5 - Open Source Show and Tell
Jan 2 - TBD
Feb 6 - DBUS
Mar 5 - Setting up a platform-independent home/small office network using
Linux
