Well, assume you're right, then I and many developers have to live with this fact then.
I would like to make myself clear abit though. Whatever decision they made over 40 years about limiting the access to port 0-1024, I dont question, or ask to change, or agree upon or disagree with. I just think if there is something they can do that what they try to protect would work, and the problem we face would be solved. See the number of response to this topic obvious shows that there's some concern/issues/misunderstanding/inconvinience. Whatever you call it. My feeling as a developer is that kernel develoeprs would make life better, whether it's a matter of convinient (without sacrafice security or whatever else). Ofcourse, there's other priority that make no body care to this about this issues. But that is another story. I think this was asked enough to have a good talk about. I also thought that this is a relative easy to change in the kernel (for the kernel dev. expert). I also don't think it would be a security problem or backward compatable problem (since the admin must allow some users to use port 80 for it to work). About the work around terminology, whatever you call it, and I may use it wrongly, but I think it's a hassle to do other stuff just for this little thing. You may think it's not a hassle, it's nothing you maysay. Well, it's users' votes. When there's enough on one side or another, there's maybe better reason to address it oneway or another (such as do nothing). About philosophy, and 40 years of thought. I think you have a good point on the time and all that. But time change. Things now are different than before. So, sometimes, changing is not that bad, and people/developers do that all the time. That's how Linux improve every day. On Fri, 6 Dec 2002, Turner, John wrote: > > Well, we are going around in circles. You're not understanding that the > developers HAVE thought about this issue, and have thought about it for > years (more than 40 years). It's not a mistake. Not only have they thought > about it, they've had ample opportunity to start over and implement the > "feature" you're talking about, and have decided NOT to do it. Do you get > that? Not to be rude, but nobody, nobody, is going to seriously consider > doing what you want to do in any future versions of Linux. Why on earth > would they completely reverse previous design decisions in an incremental > release instead of designing it that way from the beginning? > > The things I've suggested aren't "workarounds". "Workaround" implies > something that is done to get around a bug. That isn't the case. The > things that I (and others) have suggested are viable alternatives for doing > what you want to do, instead of destroying a major design decision that was > made years ago for very good reason. > > There's no "problem" in the kernel team from the perspective of the > privileged ports issue. The scheme is set up the way it is set up for very > good reason, and unless you have a better reason for changing it (you > don't..."convenience" is not a reason) it isn't going to get changed, at > least not as an official release. If you want to change it, you'll have to > take the source and change it yourself, find someone else to change it for > you, or pay someone to change it for you. > > John > > > -----Original Message----- > > From: Vy Ho [mailto:[EMAIL PROTECTED]] > > Sent: Friday, December 06, 2002 11:51 AM > > To: Tomcat Users List > > Subject: RE: Why run tomcat as root > > > > > > > > Thank you for your comment. However, I think you gave a good > > practical > > work around for now, when the kernel is not there yet. But that also > > means many developers still have to search for a solution. I > > think kernel > > developers should think about this issues, and also similar > > issues, and > > come up with a good one. I don't think anyone need to hack into it if > > they are not expert in the kernel yet. For now, I think > > using redirect > > and taken your advice is a right thing to do. I only want to > > say that the > > problem is in the kernel team, and they should fix that in the future. > > Note that I haven't develop any kernel. My suggestion is not > > the best, > > but hey, that means there's a better one out there, and I > > hope it'll make > > into the next release (too bad, 2.6 feature already is frozen :-). > > > > > > On Fri, 6 Dec 2002, Turner, John wrote: > > > > > > > > There is already a process and there are several tools for > > delegating > > > superuser access to a non-superuser account in specific > > circumstances, and > > > protecting against misuse of same. Research things like > > the sudo tool, > > > chroot jails, etc. Makes much more sense to me than > > hacking around in the > > > kernel. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Vy Ho [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, December 06, 2002 11:12 AM > > > > To: Tomcat Users List > > > > Subject: RE: Why run tomcat as root > > > > > > > > > > > > > > > > > > > > Very good point, but what if the administrator > > him/herself grand this > > > > access to this particular user? Linux and Unix is all about > > > > flexibility > > > > right? Yes, kernel would be to be changed. But I thought I > > > > already have > > > > that, and if it's not, then it's worth a change, versus > > thousands and > > > > thousands of developers has to work around it (take it millions). > > > > > > > > > > > > > > > > On Thu, 5 Dec 2002, Turner, John wrote: > > > > > > > > > > > > > > Switching UNIX/Linux to allow non-privileged users to bind > > > > to privileged > > > > > ports would require fairly major modifications to the > > > > kernel. There's no > > > > > runtime parameter that can be set to magically allow > > > > regular user accounts > > > > > to bind to a privileged port. > > > > > > > > > > Let's remember that the privileged port restriction is > > > > there for a reason, a > > > > > very valid reason. Would you really want just any user on > > > > your server to be > > > > > able to install a homegrown listener on port 80? I sure > > > > wouldn't...the > > > > > potential for malicious use is huge. Imagine somebody > > > > getting a regular > > > > > user account on one of Amazon.com's web servers in their > > > > web server farm, > > > > > then installing a "web server" on port 80 (or 443) that > > > > would simply look > > > > > for traffic starting with "3", "4" or "5" (first digits for > > > > valid credit > > > > > cards) and copy the traffic to an external location. > > > > > > > > > > Sometimes it helps to consider the bigger picture. The > > > > people who wrote > > > > > UNIX weren't stupid. They did things for a reason. > > > > Sometimes the reason > > > > > seems silly, sometimes it seems outdated, but after review, > > > > it usually makes > > > > > perfect sense. Linus and the rest of the Linux hackers > > > > could have easily > > > > > changed this when they wrote the first Linux kernel, but > > > > they didn't. So, > > > > > you've got two LARGE groups of people over a combined span > > > > of about 45 years > > > > > (30+ for UNIX, 10 or so for Linux) choosing to make ports > > > > less than 1024 > > > > > privileged. That's good enough for me...I'll devote my > > > > efforts to something > > > > > else rather than trying to circumvent something that's so > > > > obviously there > > > > > for good reason. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Vy Ho [mailto:[EMAIL PROTECTED]] > > > > > > Sent: Thursday, December 05, 2002 3:48 PM > > > > > > To: Tomcat Users List > > > > > > Subject: RE: Why run tomcat as root > > > > > > > > > > > > > > > > > > > > > > > > Can unix admin configure his OS to let normal app to run port > > > > > > 80? I say > > > > > > this because Unix is very configurable. Why you have to do > > > > > > so much coding > > > > > > just to access port 80, why not just look at it a > > different way? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > To unsubscribe, e-mail: > > > > > > <mailto:[EMAIL PROTECTED]> > > > > > > For additional commands, e-mail: > > > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
