On Wed, 23 Feb 2005 00:31:54 +0530, Rajiv Lodha <[EMAIL PROTECTED]> wrote:
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Siddhartha Basu
> Sent: Tuesday, February 22, 2005 8:28 PM
> To: [email protected]
> Subject: Re: [ilug-cal] Login expiration
>
> On Mon, 21 Feb 2005 22:40:09 +0530, Rajiv Lodha <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Siddhartha Basu
> > Sent: Monday, February 21, 2005 8:34 PM
> > To: [email protected]
> > Subject: Re: [ilug-cal] Login expiration
> >
> > Hi,
> >
> > On Mon, 21 Feb 2005 10:36:53 +0530, Rajiv Lodha <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > > "Well, if you are careful to link your binary staticly"
> > >
> > > Programmers (or atleast me) are very lazy, just to avoid any package
> > > dependency,
> >
> > Correct me if i wrong, the differences for staticaly linked binary as
> > is see are file size increase and choosing the appropiate linking
> > library during compile time. So, you could be lazy and produce
> > staticaly linked binaries. Moreover, static linking also gives you the
> > luxury of not documenting all of your dependency.
> >
> > I wonder why linux kernel is provided as source and not as a statically
> > linked binary.
>
> The binary based distro do provide it as binary together with source codes.
> Now i am not clear why being a fellow linux user you are enquiring
> about linux kernel being provided as source. Do you want to have the
> rationale behind its availability as source code or it's just a
> counter argument to my point. In the first case i am happy to help you
> and in the second case i failed to see any proper connection and
> context of your point following my statement. Neither do i see any
> logical explanation. Please clarify.
>
> I am not enquiring about linux kernel, just take it as a comment.
Well, if you are well aware about linux kernel then what is the point
of making the comment?
>
>
> >
> > > i use the full install option in FC / RH . ;-)
> > >
> > > "Why is a shell script _always_ to be preferred over a binary"?
> > >
> > > Sorry, let me correct, not a "Shell Script", but any script ..
> > >
> > > Generally ... web masters or hosting providers dont allow us to
> > > use/execute binaries on there servers, so a lot of task needs to be
> > > ported on to "scripts" (Shell, perl, batch files, vbs etc) .
> >
> > >
> > > Also, the content of a binary cannot be reviewed without executing,
> > > what if the loop goes forever, it will jst bring down the server etc.
> > > but with a script ... you can see the codes, if there are no logical
> > > errors, you can schedule them on your webservers.
> >
> > I see your point. But lets examine another point of view. The entire
> > webserver is running on binaries and they are accepting it on the
> > basis of trust. I don't think they review each and every source code,
> > compile and execute thereafter. So,they might accept binaries
> > depending on the source. Moreover, there might be a situation which
> > demands binaries. The service provider could easily review your
> > source code and if satisfied just execute your makefile and they are
> > done.
> >
> > There is a "little" difference between the binaries which the Apache or
> PHP
> > Group provides, or the binaries which a local guy (like me) provides.
>
> Right. That validates my point of trusted source.
>
> Just follow what I was saying and what you've said - Web masters do not
> allow "US" (Programmers/coders) to upload binary files and then get it
> executed on the web server.
Let me clarify before i proceed any further. You mean to say in the
entire world no web service provide allow any client(programmer/coder)
to upload any binary. Does this include both the shared web space
package provider and colocalize service provider. Is it a prefered
thing or never situation.
>No where I have said that, they don't trust
> apache, or php guys.
And i said they accept mission critical binaries from trusted source
such as apache org foundation. That's why they will not be ready to
accept a apache rpm packaged by you or any unknown third party.
>
> This is the reason, why you don't see much of cgi-bin these days, they are
> migrating to asp/php/jsp/cfm, and all these are "Scripts".
That's not the only reason, it's also because of the speed of the
execution and less taxing for the resources. Those script based
techniques have the advantages of having the logic embeded in html.
>
>
> >
> >
> > >
> > > Also, for security reasons, what if the executable carries out some
> > > different job on your machine (shutdown -h now, reboot) ??
> >
> > I don't think a properly configured and sercured web service provider
> > will give any user the privillege to execute such important system
> > command and others. Moreover, they also restrict your resource, the no
> > of background processes you could run at a time.
> >
> > Ok shutdown -h now wont be allowed, but what about this - ?
> >
> > 1.
> > While(true)
> > {
> > fprintf(fFilePointer,"This is a rainy day");
> > }
> >
> > or say
> >
> > 2.
> > main()
> > {
> > main();
> > }
> >
> > Or this (WCS) -
> >
> > 3.
> > main()
> > {
> > //get the idea, syntax is wrong
> > typedef struct x objSt[500000];
> > for(i=1;i<500000;i++)
> > {
> > objSt[i] = malloc(sizeof(x) * 100);
> > }
> > }
> >
>
> I was well aware about your point before you posted your code
> snippets. These are the obvious way of hurting the server and the
> aware admins will be taking enough precautions to prevent them from
> happening.
>
> How would you make out if this was provided in a binary format ?
>
> > Ok you can say, the administrator can kill those processes, but we all
> know
> > our network administrators :-)
> Well, what i see is immediate suspension of your account :-)
>
> Not yet, as I told you :-))
Well, i would be prefer to take my business elsewhere after having
such lousy net admin.
>
> >
> > There are lot of other dirty methods, that's why binaries are not
> accepted.
> >
> > Also, if I have bought a webspace for hosting my website, why should I
> need
> > to do all these things, simply I wont,
>
> > but there is always a dirty "but" .....
> >
> > Even Scripts can cause harm, but (again but), the web masters can review
> > these scripts, and so ... its not so dangerous.
>
> I don't disagree with your points. What i am trying to put forward is
> that binaries could be acceptable depending on context and situation.
> It is not absolutely unacceptable.
>
> Say the 'login expiration' program will be tougher to push as binary
> because it obviously involves system interaction and manipulation with
> user privileges which might poses security threats. However, if i
> wrote a string matching program in C(for obvious speed reason) and
> want to provide a web wrapper for it, i could easily run it from my
> restricted home environment and possibly be granted the privilege to
> run it.
>
> When you statically link a library, then dependency problem is solved, but
> the user has to pay the cost, more space, more ram. And say if everybody
> follows this rule, then what will happen?
That's why the rule is followed under certain circumstances.
>
> Have you seen the file size of available commands in /usr/bin ? very tiny,
> but if statically linked, I guess each would cross around 1-2 mb ! and what
> more, they are storing the same libraries with themselves, which could have
> been easily shared, if dynamically linked, and which are .
>
> Back to login expiration - the script was to be used with cron[TAB],
> scheduled to run each and every minute (if you need Accuracy) and if you
> would have developed that in "C", statically compiled, then think of the
> situation!
Let me refresh.
In the context of login expiration program you said "You cannot
"easily" port the binary to other os/distro's, there can be a library
/ processor or gcc issue"(2/18/05). Firstly, nobody mentioned
deplyoing it as binary before that. You assumed it. The entire
question of binary came after that. So, if porting is an big issue for
you, it could easily be distributed as source code, no question of
static compiling. Moreover, i also could'nt recall the original poster
to raise any issue about porting.
Secondly, in the same context you also mentioned that shell script is
preferable. However, when asked for clarification, you went on to
borrow the logic of its preference in web environment. What is the
relation? What a login expiration program has to do with a
coder/programmer account in a web hosting providers space.
>
> It seems you were not following this thread from the beginning I was just
> trying to explain - "Why is a shell script _always_ to be preferred over a
> binary".
> I never said that "never accept a binary"
Who said you did not. I just tried to provide a different point of
view against the logic you have constructed to justify your statement.
-siddhartha
--
To unsubscribe, send mail to [EMAIL PROTECTED] with the body
"unsubscribe ilug-cal" and an empty subject line.
FAQ: http://www.ilug-cal.org/node.php?id=3
