1. I think that Yoav explained that in unix this function actually will change the file permissions as part of its test.
2. This may be a good idea but it also means that the test will occur more than once, perhaps frequently for a heavy user of the admin app, lending to an overhead, however small. -----Original Message----- From: Fred Stluka [mailto:[EMAIL PROTECTED] Sent: 19 September 2004 23:20 To: Tomcat Users List Subject: Re: why is tomcat-users.xml rewritten ? I've just searched the archives and it seems that this question comes up every few months at least. The behavior of rewriting tomcat-users.xml and changing its permissions to match the Tomcat umask surprises enough people that it seems worth changing if possible. I put a lot of faith in "the principal of least astonishment". My understanding is that the only reason for the rewrite is to confirm that the Tomcat admin app will have write access to the tomcat-users.xml file if the admin app is ever used. Two questions: 1. Why not use java.io.File.canWrite()? It confirms the ability to rewrite the file without actually doing so. Works fine on both Linux and Windows 2000, so I assume it is a fully portable solution. 2. Couldn't the rewrite be deferred until necessary? Perhaps when the admin app accepts a valid login? Or when a user tries to use the admin app to modify the tomcat-users.xml file? Why check so far in advance? There is always the risk that the permissions could be modified manually after the check at startup, and before the admin app actually needs to write, so the admin app must be prepared for failure anyhow. Why not just have it check when it needs to and report the error to the user then? --Fred -------------------------------------------------------------------------- Fred Stluka -- mailto:[EMAIL PROTECTED] -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- "Glad to be of service!" -------------------------------------------------------------------------- Steffen Heil wrote: > Hi > > > Each time tomcat is restarted the file tomcat-users.xml is rewritten. It > is horrible since my umask being 0022 the file which stores passwords become > world readable. Obviously this file has to be read my the server but I do > not see any valuable reason to write it back opening a serious security > hole. > > PLEASE, search the archive of this list before mailing. > This question, including some ways around it have been on the list recently. > > See also posting of Yoav below. > > Regards, > Steffen > > -----Ursprüngliche Nachricht----- > Von: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 15. September 2004 20:48 > An: Tomcat Users List > Betreff: RE: Why does startup of Tomcat 5.0.28 server make tomcat-users.xml > world-readable?... > > Hi, > > >However, I still wonder: > >1. Why does Tomcat re-write the tomcat-users.xml file at > > startup? > > This I already answered: Tomcat rewrites the tomcat-users.xml at startup to > ensure it has permissions on it, because the admin webapp must have these > permissions to allow editing of user information. > > >2. Why does it use the umask value instead of just leaving > > the protections as they were before it updated the file? > > This is the java.io.File default behavior: we don't modify anything and > don't want to have platform-specific or native code in Tomcat. If you look > at the java.io.File JavaDoc, you'll see there's no portable way to control > this. > > >3. Isn't this a problem for most Tomcat installations, since > > without the umask I had applied to my tomcat user, the > > default umask is 002, not 022, so the tomcat-users.xml > > file would be changed to 664, not merely 644, at each > > startup? Seems like the default Tomcat behavior > > introduces a security risk. > > Judging by the fact this is raised about once a year on the mailing list, > I'd say the majority of people don't care. Secure installations take care > with their umasks from the beginning, so for them this is not an issue. > > Yoav --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
