-----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. > > > 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. No where I have said that, they don't trust apache, or php guys. 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". > > > > > > 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 :-)) > > 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? 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! 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". I do agree, binaries can also be accepted (and they are), but not to be preferred over scripts (there can be some case where you want to hide your logic, you don't want other guys to see how you do that, so in those cases we do need a binary). -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 -- 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
