John, Your theory is wrong, and here is why : how would Tomcat be able to change your permissions, if you set an "access-denied" type of permission to Tomcat so that he -cannot- change your permissions ? This is obvious : you prevent Tomcat from accessing some of your JSP files : therefore he won't be able to access them neither change their permissions... Just logical.
My problem here is different, and doesn't have anything to do with a Microsoft tool or the like (since like I said, Tomcat is installed on a Linux server, and besides, Microsoft users don't have such "tools" or "knowledge" to change permissions back to Tomcat4 users (why would they do that ?)). Have to check if it's Samba related, thanks for the suggestion. Definitely, what I say here is for true : restart Tomcat4 and all your permissions you might have set before in your web application folder are replaced, and I'm talking about Linux OS, didn't try it on Windows. And I want to prevent this from happening. Anyone has an idea ? Thank you -----Message d'origine----- De : John Turner [mailto:[EMAIL PROTECTED] Envoy� : vendredi, 22. ao�t 2003 18:37 � : Tomcat Users List Objet : Re: RE : Folder Permissions taken over by Tomcat 4 I still don't believe it. The reason I don't believe it is simple: if I change the permissions in my Context or one of its subdirectories or files to something that prevents Tomcat from using the resources (JSP file or whatever), Tomcat does not change the permissions back to what it needs to work, instead my apps fail and throw errors like crazy. If Tomcat is doing what you say it is doing, I would never get errors, because Tomcat would just merrily go around and change permissions on resources so that it was happy, which is what you say it is doing. If anything, it isn't Tomcat that's doing it to you...if I had to guess, it would be samba or something on one of the Windows clients like some goofy "tool" Microsoft has like a fast indexer or some other munged up app (much more likely). John Hertenstein Alain wrote: > Yes I do confirm it again (at least on Linux Red Hat 7.2, as long as > the OS has anything to do with it). Ok I repeat : > > - have a web application configured on Tomcat 4.0.3, in a folder like > webapps/myApps > - share an application's sub-folder (f.ex. webapps/myApps/documents), > and try to set permissions (read & write) and ownership for specific > user accounts which will access this sub-folder through SMB. > - restart Tomcat 4 : all these permissions in the > webapps/myApps/documents folder are gone. And furthermore, the > folder's Ownership (maybe the problem lies here actually...) is set to > user : tomcat4, and group : tomcat4 > > I can send screenshots if you don't believe this... > Nobody heard of this before !? > Alain > > -----Message d'origine----- > De : John Turner [mailto:[EMAIL PROTECTED] > Envoy� : vendredi, 22. ao�t 2003 14:40 > � : Tomcat Users List > Objet : Re: Folder Permissions taken over by Tomcat 4 > > > > You're saying Tomcat runs around and changes the directory permissions? > I find that really hard to believe...I'm running Tomcat 3.1, 4.1.12, > 4.1.18, and 4.1.27 in various places and have never seen this behavior. > > John > > Hertenstein Alain wrote: > > >>Hello, >> >>We have a Red Hat Linux 7.2 Server with Tomcat v4.0.3 installed, and a >>web application configured, let's say myApps. In this webapps/myApps >>folder, there are folders which we have shared through SMB so that >>Windows users can access them, and we have also changed the folder's >>permissions, so that these users can modify their contents. Everything >>works fine. >> >>The problem here is when we have to restart Tomcat 4, all permissions >>under that webapps/myApps folder are restored this way -> User : >>Tomcat 4, Group : Tomcat 4. So this means that all our permissions >>settings are cleared ! And we have to set them back again each time we >>restart Tomcat 4 (in case of a server reboot, or major application >>change, etc), which is quite annoying. >> >>Is there a way to avoid this ? >>Thank you very much >>Alain >> >> >>********************************************************************** >> This email and any files transmitted with it are confidential and >>intended solely for the use of the individual or entity to whom they >>are addressed. If you have received this email in error please notify >>the system manager. >>********************************************************************** >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
