Re: [EXTERNAL EMAIL] About granting permissions to Tomcat JVM
Are you using FileInputStream or FileOutputSteam on the file and closing the stream before deletion? If so, change to Files.newInputSteam or Files.newOutputStream. One of our application (not a web application) was running out of file handles even though we were closing the file handles. Everything was in try block and we did verify the handles were closed as far our code was concerned. It turned out that JVM does not close the actual handles until late in the game. There is a bug on openjdk bugs tracker that discusses this. After using Files, our issue was resolved. If you are closing the file and JVM is not releasing the handles, this sounds very similar to the issue we faced. Regards, Niranjan On 10/8/22 09:36, Martin Moore wrote: Hello, I am facing a problem using Tomcat V8 with my J2ee app that deletes (using file. delete() Java 8) a file from disk (Windows). The file is actually deleting only on application level meaning that the application does not see the file anymore ZjQcmQRYFpfptBannerStart This Message Is From an Untrusted Sender You have not previously corresponded with this sender. ZjQcmQRYFpfptBannerEnd Hello, I am facing a problem using Tomcat V8 with my J2ee app that deletes (using file.delete() Java 8) a file from disk (Windows). The file is actually deleting only on application level meaning that the application does not see the file anymore but if i open the folder i still see the file which is then locked by Java process. I only get the file to be removed physically when i close the Tomcat instance. Does this problem relate to permissions in catalina.policy ? How to solve this?
AW: About granting permissions to Tomcat JVM
Hello,
> -Ursprüngliche Nachricht-
> Von: Martin Moore
> Gesendet: Sonntag, 9. Oktober 2022 17:59
> An: Tomcat Users List
> Betreff: Re: About granting permissions to Tomcat JVM
>
> @thomas.hoffm...@speed4trade.com.invalid
> how to use the debugger in
> this case ?any documentation pls ?
For debugging you need the sources. Either you have a development environment
where you start debugging.
Alternatively you can open a JMX port and do remote debugging (e.g. with
eclipse)
Details about remote debugging are e.g.
https://stackify.com/java-remote-debugging/
I don’t think that there a libs or something else missing. As you see an open
file handle, the next step is to
figure out which part of the program is causing the left open file handle.
> @Rob Sargent i posted most of the methods used in the app, but yes JVM is
> holding off on deleting the file...
>
> Le dim. 9 oct. 2022 à 17:31, Thomas Hoffmann (Speed4Trade GmbH)
> a écrit :
>
> > Hello,
> >
> > > About the methods i use in the application along with file.delete()
> > (which is
> > > what this post is about) I use File[] files = new
> > > File("C:\\SomeFolder").listFiles();
> > > file.getName();
> > > file.lastModified()
> > > Path path = Paths.get(fileName);
> > > Would any of these cause the lock on the file ?
> >
> > They don't look suspicious to me. What you could do is, use the
> > debugger to go step by step.
> > In parallel, use the ProcessExplorer to see at which point the file
> > handle appears.
> > Maybe it is more hidden in some other routines which might use a
> > MappedByteBuffer to read or write.
> >
> >
> > >
> > > Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
> > > a écrit :
> > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Martin Moore
> > > > > Gesendet: Sonntag, 9. Oktober 2022 15:37
> > > > > An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
> > > > >
> > > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > > >
> > > > > the ProcessExplorer shows that a Java process is running on the
> > > > > file and
> > > > this
> > > > > only after actually performing the delete from Java.
> > > >
> > > >
> > > > Some possibilities for file locking.
> > > > - the upload process didn’t close the streams properly
> > > > - You use http2 and sendfile
> > > > - You are using a MappedByteBuffer before deletion:
> > > > https://bugs.openjdk.org/browse/JDK-4724038
> > > >
> > > > ... just some ideas which cause file locking ...
> > > >
> > > > > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
> > > > > a écrit :
> > > > >
> > > > > > Hello,
> > > > > > this might be a behavior of the underlying OS.
> > > > > > If the file is locked, it is marked for deletion and when the
> > > > > > file lock is released, the file is physically deleted.
> > > > > >
> > > > > > Maybe you can check with ProcessExplorer from MS whether there
> > > > > > is an open file handle on this file.
> > > > > >
> > > > > > Greetings,
> > > > > > Thomas
> > > > > >
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von: Martin Moore
> > > > > > > Gesendet: Sonntag, 9. Oktober 2022 09:56
> > > > > > > An: Tomcat Users List ;
> > > > > > > ma...@apache.org
> > > > > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > > > > >
> > > > > > > Hello Mark,
> > > > > > >
> > > > > > > I don't know if the SecurityManager is enabled or not (how
> > > > > > > to disable it
> > > > > > > btw?)
> > > > > > > I set the env var CATALINA_HOME to be C:/Program
> > > > > > > Files/Apache-Tomcat-8/ The files in question are stored in
> > > > > > > Desktop/SomeFolder
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas
> > > >
Re: About granting permissions to Tomcat JVM
@Rob this is the command: %CATALINA_HOME%\bin\startup.bat
Le dim. 9 oct. 2022 à 21:30, Rob Sargent a écrit :
>
>
> > On Oct 9, 2022, at 8:54 AM, Martin Moore
> wrote:
> >
> > @thomas.hoffm...@speed4trade.com.invalid
> > how to use the debugger in
> this
> > case ?any documentation pls ?
> > @Rob Sargent i posted most of the methods used in the app, but yes JVM is
> > holding off on deleting the file...
>
> I think this might be a config issue. What is the full Java command with
> variables expanded
>
> >
> >> Le dim. 9 oct. 2022 à 17:31, Thomas Hoffmann (Speed4Trade GmbH)
> >> a écrit :
> >>
> >> Hello,
> >>
> >>> About the methods i use in the application along with file.delete()
> >> (which is
> >>> what this post is about) I use File[] files = new
> >>> File("C:\\SomeFolder").listFiles();
> >>> file.getName();
> >>> file.lastModified()
> >>> Path path = Paths.get(fileName);
> >>> Would any of these cause the lock on the file ?
> >>
> >> They don't look suspicious to me. What you could do is, use the debugger
> >> to go step by step.
> >> In parallel, use the ProcessExplorer to see at which point the file
> handle
> >> appears.
> >> Maybe it is more hidden in some other routines which might use a
> >> MappedByteBuffer to read or write.
> >>
> >>
> >>>
> >>> Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
> >>> a écrit :
> >>>
> >>>>
> >>>>> -Ursprüngliche Nachricht-
> >>>>> Von: Martin Moore
> >>>>> Gesendet: Sonntag, 9. Oktober 2022 15:37
> >>>>> An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
> >>>>>
> >>>>> Betreff: Re: About granting permissions to Tomcat JVM
> >>>>>
> >>>>> the ProcessExplorer shows that a Java process is running on the file
> >>>>> and
> >>>> this
> >>>>> only after actually performing the delete from Java.
> >>>>
> >>>>
> >>>> Some possibilities for file locking.
> >>>> - the upload process didn’t close the streams properly
> >>>> - You use http2 and sendfile
> >>>> - You are using a MappedByteBuffer before deletion:
> >>>> https://bugs.openjdk.org/browse/JDK-4724038
> >>>>
> >>>> ... just some ideas which cause file locking ...
> >>>>
> >>>>> Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
> >>>>> a écrit :
> >>>>>
> >>>>>> Hello,
> >>>>>> this might be a behavior of the underlying OS.
> >>>>>> If the file is locked, it is marked for deletion and when the file
> >>>>>> lock is released, the file is physically deleted.
> >>>>>>
> >>>>>> Maybe you can check with ProcessExplorer from MS whether there is
> >>>>>> an open file handle on this file.
> >>>>>>
> >>>>>> Greetings,
> >>>>>> Thomas
> >>>>>>
> >>>>>>> -Ursprüngliche Nachricht-
> >>>>>>> Von: Martin Moore
> >>>>>>> Gesendet: Sonntag, 9. Oktober 2022 09:56
> >>>>>>> An: Tomcat Users List ;
> >>>>>>> ma...@apache.org
> >>>>>>> Betreff: Re: About granting permissions to Tomcat JVM
> >>>>>>>
> >>>>>>> Hello Mark,
> >>>>>>>
> >>>>>>> I don't know if the SecurityManager is enabled or not (how to
> >>>>>>> disable it
> >>>>>>> btw?)
> >>>>>>> I set the env var CATALINA_HOME to be C:/Program
> >>>>>>> Files/Apache-Tomcat-8/ The files in question are stored in
> >>>>>>> Desktop/SomeFolder
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>> Le dim. 9 oct. 2022 à 08:00, Mark Thomas a
> >>>>>>> écrit
> >>>> :
> >>>>>>>
> >>>>>>>> On 08/10/2022 17:36, Martin Moore wrote:
> >>>>>>>>> Hello,
> >>>>>
Re: About granting permissions to Tomcat JVM
> On Oct 9, 2022, at 8:54 AM, Martin Moore wrote:
>
> @thomas.hoffm...@speed4trade.com.invalid
> how to use the debugger in this
> case ?any documentation pls ?
> @Rob Sargent i posted most of the methods used in the app, but yes JVM is
> holding off on deleting the file...
I think this might be a config issue. What is the full Java command with
variables expanded
>
>> Le dim. 9 oct. 2022 à 17:31, Thomas Hoffmann (Speed4Trade GmbH)
>> a écrit :
>>
>> Hello,
>>
>>> About the methods i use in the application along with file.delete()
>> (which is
>>> what this post is about) I use File[] files = new
>>> File("C:\\SomeFolder").listFiles();
>>> file.getName();
>>> file.lastModified()
>>> Path path = Paths.get(fileName);
>>> Would any of these cause the lock on the file ?
>>
>> They don't look suspicious to me. What you could do is, use the debugger
>> to go step by step.
>> In parallel, use the ProcessExplorer to see at which point the file handle
>> appears.
>> Maybe it is more hidden in some other routines which might use a
>> MappedByteBuffer to read or write.
>>
>>
>>>
>>> Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
>>> a écrit :
>>>
>>>>
>>>>> -Ursprüngliche Nachricht-
>>>>> Von: Martin Moore
>>>>> Gesendet: Sonntag, 9. Oktober 2022 15:37
>>>>> An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
>>>>>
>>>>> Betreff: Re: About granting permissions to Tomcat JVM
>>>>>
>>>>> the ProcessExplorer shows that a Java process is running on the file
>>>>> and
>>>> this
>>>>> only after actually performing the delete from Java.
>>>>
>>>>
>>>> Some possibilities for file locking.
>>>> - the upload process didn’t close the streams properly
>>>> - You use http2 and sendfile
>>>> - You are using a MappedByteBuffer before deletion:
>>>> https://bugs.openjdk.org/browse/JDK-4724038
>>>>
>>>> ... just some ideas which cause file locking ...
>>>>
>>>>> Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
>>>>> a écrit :
>>>>>
>>>>>> Hello,
>>>>>> this might be a behavior of the underlying OS.
>>>>>> If the file is locked, it is marked for deletion and when the file
>>>>>> lock is released, the file is physically deleted.
>>>>>>
>>>>>> Maybe you can check with ProcessExplorer from MS whether there is
>>>>>> an open file handle on this file.
>>>>>>
>>>>>> Greetings,
>>>>>> Thomas
>>>>>>
>>>>>>> -Ursprüngliche Nachricht-
>>>>>>> Von: Martin Moore
>>>>>>> Gesendet: Sonntag, 9. Oktober 2022 09:56
>>>>>>> An: Tomcat Users List ;
>>>>>>> ma...@apache.org
>>>>>>> Betreff: Re: About granting permissions to Tomcat JVM
>>>>>>>
>>>>>>> Hello Mark,
>>>>>>>
>>>>>>> I don't know if the SecurityManager is enabled or not (how to
>>>>>>> disable it
>>>>>>> btw?)
>>>>>>> I set the env var CATALINA_HOME to be C:/Program
>>>>>>> Files/Apache-Tomcat-8/ The files in question are stored in
>>>>>>> Desktop/SomeFolder
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Le dim. 9 oct. 2022 à 08:00, Mark Thomas a
>>>>>>> écrit
>>>> :
>>>>>>>
>>>>>>>> On 08/10/2022 17:36, Martin Moore wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I am facing a problem using Tomcat V8 with my J2ee app that
>>>>>>>>> deletes
>>>>>>>> (using
>>>>>>>>> file.delete() Java 8) a file from disk (Windows). The file
>>>>>>>>> is actually deleting only on application level meaning that
>>>>>>>>> the application does not see the file anymore but if i open
>>>>>>>>> the folder i still see the file which
>>>>>>>> is
>&g
Re: About granting permissions to Tomcat JVM
@thomas.hoffm...@speed4trade.com.invalid
how to use the debugger in this
case ?any documentation pls ?
@Rob Sargent i posted most of the methods used in the app, but yes JVM is
holding off on deleting the file...
Le dim. 9 oct. 2022 à 17:31, Thomas Hoffmann (Speed4Trade GmbH)
a écrit :
> Hello,
>
> > About the methods i use in the application along with file.delete()
> (which is
> > what this post is about) I use File[] files = new
> > File("C:\\SomeFolder").listFiles();
> > file.getName();
> > file.lastModified()
> > Path path = Paths.get(fileName);
> > Would any of these cause the lock on the file ?
>
> They don't look suspicious to me. What you could do is, use the debugger
> to go step by step.
> In parallel, use the ProcessExplorer to see at which point the file handle
> appears.
> Maybe it is more hidden in some other routines which might use a
> MappedByteBuffer to read or write.
>
>
> >
> > Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
> > a écrit :
> >
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Martin Moore
> > > > Gesendet: Sonntag, 9. Oktober 2022 15:37
> > > > An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
> > > >
> > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > >
> > > > the ProcessExplorer shows that a Java process is running on the file
> > > > and
> > > this
> > > > only after actually performing the delete from Java.
> > >
> > >
> > > Some possibilities for file locking.
> > > - the upload process didn’t close the streams properly
> > > - You use http2 and sendfile
> > > - You are using a MappedByteBuffer before deletion:
> > > https://bugs.openjdk.org/browse/JDK-4724038
> > >
> > > ... just some ideas which cause file locking ...
> > >
> > > > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
> > > > a écrit :
> > > >
> > > > > Hello,
> > > > > this might be a behavior of the underlying OS.
> > > > > If the file is locked, it is marked for deletion and when the file
> > > > > lock is released, the file is physically deleted.
> > > > >
> > > > > Maybe you can check with ProcessExplorer from MS whether there is
> > > > > an open file handle on this file.
> > > > >
> > > > > Greetings,
> > > > > Thomas
> > > > >
> > > > > > -Ursprüngliche Nachricht-
> > > > > > Von: Martin Moore
> > > > > > Gesendet: Sonntag, 9. Oktober 2022 09:56
> > > > > > An: Tomcat Users List ;
> > > > > > ma...@apache.org
> > > > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > > > >
> > > > > > Hello Mark,
> > > > > >
> > > > > > I don't know if the SecurityManager is enabled or not (how to
> > > > > > disable it
> > > > > > btw?)
> > > > > > I set the env var CATALINA_HOME to be C:/Program
> > > > > > Files/Apache-Tomcat-8/ The files in question are stored in
> > > > > > Desktop/SomeFolder
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a
> > > > > > écrit
> > > :
> > > > > >
> > > > > > > On 08/10/2022 17:36, Martin Moore wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that
> > > > > > > > deletes
> > > > > > > (using
> > > > > > > > file.delete() Java 8) a file from disk (Windows). The file
> > > > > > > > is actually deleting only on application level meaning that
> > > > > > > > the application does not see the file anymore but if i open
> > > > > > > > the folder i still see the file which
> > > > > > > is
> > > > > > > > then locked by Java process. I only get the file to be
> > > > > > > > removed physically when i close the Tomcat instance.
> > > > > > > >
> > > > > > > > Does this problem relate to permissions in catalin
Re: About granting permissions to Tomcat JVM
> On Oct 8, 2022, at 9:36 AM, Martin Moore wrote: > > Hello, > > I am facing a problem using Tomcat V8 with my J2ee app that deletes (using > file.delete() Java 8) a file from disk (Windows). The file is actually > deleting only on application level meaning that the application does not > see the file anymore but if i open the folder i still see the file which is > then locked by Java process. I only get the file to be removed physically > when i close the Tomcat instance. > > Does this problem relate to permissions in catalina.policy ? > How to solve this? This has a familiar ring to it. Can we see your entire java command (minus secrets) and any environment variables which have a capital X. I suspect the JVM is holding off on deleting the file until exit and IIRC there’s a setting for that. But it has been a while since I dealt with this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: About granting permissions to Tomcat JVM
Hello,
> About the methods i use in the application along with file.delete() (which is
> what this post is about) I use File[] files = new
> File("C:\\SomeFolder").listFiles();
> file.getName();
> file.lastModified()
> Path path = Paths.get(fileName);
> Would any of these cause the lock on the file ?
They don't look suspicious to me. What you could do is, use the debugger to go
step by step.
In parallel, use the ProcessExplorer to see at which point the file handle
appears.
Maybe it is more hidden in some other routines which might use a
MappedByteBuffer to read or write.
>
> Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
> a écrit :
>
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Martin Moore
> > > Gesendet: Sonntag, 9. Oktober 2022 15:37
> > > An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
> > >
> > > Betreff: Re: About granting permissions to Tomcat JVM
> > >
> > > the ProcessExplorer shows that a Java process is running on the file
> > > and
> > this
> > > only after actually performing the delete from Java.
> >
> >
> > Some possibilities for file locking.
> > - the upload process didn’t close the streams properly
> > - You use http2 and sendfile
> > - You are using a MappedByteBuffer before deletion:
> > https://bugs.openjdk.org/browse/JDK-4724038
> >
> > ... just some ideas which cause file locking ...
> >
> > > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
> > > a écrit :
> > >
> > > > Hello,
> > > > this might be a behavior of the underlying OS.
> > > > If the file is locked, it is marked for deletion and when the file
> > > > lock is released, the file is physically deleted.
> > > >
> > > > Maybe you can check with ProcessExplorer from MS whether there is
> > > > an open file handle on this file.
> > > >
> > > > Greetings,
> > > > Thomas
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Martin Moore
> > > > > Gesendet: Sonntag, 9. Oktober 2022 09:56
> > > > > An: Tomcat Users List ;
> > > > > ma...@apache.org
> > > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > > >
> > > > > Hello Mark,
> > > > >
> > > > > I don't know if the SecurityManager is enabled or not (how to
> > > > > disable it
> > > > > btw?)
> > > > > I set the env var CATALINA_HOME to be C:/Program
> > > > > Files/Apache-Tomcat-8/ The files in question are stored in
> > > > > Desktop/SomeFolder
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a
> > > > > écrit
> > :
> > > > >
> > > > > > On 08/10/2022 17:36, Martin Moore wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that
> > > > > > > deletes
> > > > > > (using
> > > > > > > file.delete() Java 8) a file from disk (Windows). The file
> > > > > > > is actually deleting only on application level meaning that
> > > > > > > the application does not see the file anymore but if i open
> > > > > > > the folder i still see the file which
> > > > > > is
> > > > > > > then locked by Java process. I only get the file to be
> > > > > > > removed physically when i close the Tomcat instance.
> > > > > > >
> > > > > > > Does this problem relate to permissions in catalina.policy ?
> > > > > >
> > > > > > Unlikely.
> > > > > >
> > > > > > Are you using a SecurityManager?
> > > > > >
> > > > > > > How to solve this?
> > > > > >
> > > > > > Where, exactly, are you storing these files? Where, exactly,
> > > > > > are CATALINA_HOME and CATALINA_BASE?
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > --
> > > > > >
> > > > > > --- To unsubscribe, e-mail:
> > > > > > users-unsubscr...@tomcat.apache.org
> > > > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About granting permissions to Tomcat JVM
About the methods i use in the application along with file.delete() (which
is what this post is about)
I use File[] files = new File("C:\\SomeFolder").listFiles();
file.getName();
file.lastModified()
Path path = Paths.get(fileName);
Would any of these cause the lock on the file ?
Le dim. 9 oct. 2022 à 16:03, Thomas Hoffmann (Speed4Trade GmbH)
a écrit :
>
> > -Ursprüngliche Nachricht-
> > Von: Martin Moore
> > Gesendet: Sonntag, 9. Oktober 2022 15:37
> > An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List
> >
> > Betreff: Re: About granting permissions to Tomcat JVM
> >
> > the ProcessExplorer shows that a Java process is running on the file and
> this
> > only after actually performing the delete from Java.
>
>
> Some possibilities for file locking.
> - the upload process didn’t close the streams properly
> - You use http2 and sendfile
> - You are using a MappedByteBuffer before deletion:
> https://bugs.openjdk.org/browse/JDK-4724038
>
> ... just some ideas which cause file locking ...
>
> > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH)
> > a écrit :
> >
> > > Hello,
> > > this might be a behavior of the underlying OS.
> > > If the file is locked, it is marked for deletion and when the file
> > > lock is released, the file is physically deleted.
> > >
> > > Maybe you can check with ProcessExplorer from MS whether there is an
> > > open file handle on this file.
> > >
> > > Greetings,
> > > Thomas
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Martin Moore
> > > > Gesendet: Sonntag, 9. Oktober 2022 09:56
> > > > An: Tomcat Users List ; ma...@apache.org
> > > > Betreff: Re: About granting permissions to Tomcat JVM
> > > >
> > > > Hello Mark,
> > > >
> > > > I don't know if the SecurityManager is enabled or not (how to
> > > > disable it
> > > > btw?)
> > > > I set the env var CATALINA_HOME to be C:/Program
> > > > Files/Apache-Tomcat-8/ The files in question are stored in
> > > > Desktop/SomeFolder
> > > >
> > > > Thanks.
> > > >
> > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit
> :
> > > >
> > > > > On 08/10/2022 17:36, Martin Moore wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I am facing a problem using Tomcat V8 with my J2ee app that
> > > > > > deletes
> > > > > (using
> > > > > > file.delete() Java 8) a file from disk (Windows). The file is
> > > > > > actually deleting only on application level meaning that the
> > > > > > application does not see the file anymore but if i open the
> > > > > > folder i still see the file which
> > > > > is
> > > > > > then locked by Java process. I only get the file to be removed
> > > > > > physically when i close the Tomcat instance.
> > > > > >
> > > > > > Does this problem relate to permissions in catalina.policy ?
> > > > >
> > > > > Unlikely.
> > > > >
> > > > > Are you using a SecurityManager?
> > > > >
> > > > > > How to solve this?
> > > > >
> > > > > Where, exactly, are you storing these files? Where, exactly, are
> > > > > CATALINA_HOME and CATALINA_BASE?
> > > > >
> > > > > Mark
> > > > >
> > > > > --
> > > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > > >
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
AW: About granting permissions to Tomcat JVM
> -Ursprüngliche Nachricht- > Von: Martin Moore > Gesendet: Sonntag, 9. Oktober 2022 15:37 > An: thomas.hoffm...@speed4trade.com.invalid; Tomcat Users List > > Betreff: Re: About granting permissions to Tomcat JVM > > the ProcessExplorer shows that a Java process is running on the file and this > only after actually performing the delete from Java. Some possibilities for file locking. - the upload process didn’t close the streams properly - You use http2 and sendfile - You are using a MappedByteBuffer before deletion: https://bugs.openjdk.org/browse/JDK-4724038 ... just some ideas which cause file locking ... > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH) > a écrit : > > > Hello, > > this might be a behavior of the underlying OS. > > If the file is locked, it is marked for deletion and when the file > > lock is released, the file is physically deleted. > > > > Maybe you can check with ProcessExplorer from MS whether there is an > > open file handle on this file. > > > > Greetings, > > Thomas > > > > > -Ursprüngliche Nachricht- > > > Von: Martin Moore > > > Gesendet: Sonntag, 9. Oktober 2022 09:56 > > > An: Tomcat Users List ; ma...@apache.org > > > Betreff: Re: About granting permissions to Tomcat JVM > > > > > > Hello Mark, > > > > > > I don't know if the SecurityManager is enabled or not (how to > > > disable it > > > btw?) > > > I set the env var CATALINA_HOME to be C:/Program > > > Files/Apache-Tomcat-8/ The files in question are stored in > > > Desktop/SomeFolder > > > > > > Thanks. > > > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit : > > > > > > > On 08/10/2022 17:36, Martin Moore wrote: > > > > > Hello, > > > > > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that > > > > > deletes > > > > (using > > > > > file.delete() Java 8) a file from disk (Windows). The file is > > > > > actually deleting only on application level meaning that the > > > > > application does not see the file anymore but if i open the > > > > > folder i still see the file which > > > > is > > > > > then locked by Java process. I only get the file to be removed > > > > > physically when i close the Tomcat instance. > > > > > > > > > > Does this problem relate to permissions in catalina.policy ? > > > > > > > > Unlikely. > > > > > > > > Are you using a SecurityManager? > > > > > > > > > How to solve this? > > > > > > > > Where, exactly, are you storing these files? Where, exactly, are > > > > CATALINA_HOME and CATALINA_BASE? > > > > > > > > Mark > > > > > > > > -- > > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About granting permissions to Tomcat JVM
Hello Martin, On Sun, Oct 9, 2022 at 7:03 PM Martin Moore wrote: > > the ProcessExplorer shows that a Java process is running on the file and > this only after actually performing the delete from Java. > Sometimes Logstash gives me trouble like this. Most probably some part of the app was still holding reference to the file. Can you please ensure your app is closing all input/output streams after using them to access the file? > Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH) > a écrit : > > > Hello, > > this might be a behavior of the underlying OS. > > If the file is locked, it is marked for deletion and when the file lock is > > released, the file is physically deleted. > > > > Maybe you can check with ProcessExplorer from MS whether there is an open > > file handle on this file. > > > > Greetings, > > Thomas > > > > > -Ursprüngliche Nachricht- > > > Von: Martin Moore > > > Gesendet: Sonntag, 9. Oktober 2022 09:56 > > > An: Tomcat Users List ; ma...@apache.org > > > Betreff: Re: About granting permissions to Tomcat JVM > > > > > > Hello Mark, > > > > > > I don't know if the SecurityManager is enabled or not (how to disable it > > > btw?) > > > I set the env var CATALINA_HOME to be C:/Program Files/Apache-Tomcat-8/ > > > The files in question are stored in Desktop/SomeFolder > > > > > > Thanks. > > > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit : > > > > > > > On 08/10/2022 17:36, Martin Moore wrote: > > > > > Hello, > > > > > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that deletes > > > > (using > > > > > file.delete() Java 8) a file from disk (Windows). The file is > > > > > actually deleting only on application level meaning that the > > > > > application does not see the file anymore but if i open the folder i > > > > > still see the file which > > > > is > > > > > then locked by Java process. I only get the file to be removed > > > > > physically when i close the Tomcat instance. > > > > > > > > > > Does this problem relate to permissions in catalina.policy ? > > > > > > > > Unlikely. > > > > > > > > Are you using a SecurityManager? > > > > > > > > > How to solve this? > > > > > > > > Where, exactly, are you storing these files? Where, exactly, are > > > > CATALINA_HOME and CATALINA_BASE? > > > > > > > > Mark > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About granting permissions to Tomcat JVM
the ProcessExplorer shows that a Java process is running on the file and this only after actually performing the delete from Java. Le dim. 9 oct. 2022 à 15:23, Thomas Hoffmann (Speed4Trade GmbH) a écrit : > Hello, > this might be a behavior of the underlying OS. > If the file is locked, it is marked for deletion and when the file lock is > released, the file is physically deleted. > > Maybe you can check with ProcessExplorer from MS whether there is an open > file handle on this file. > > Greetings, > Thomas > > > -Ursprüngliche Nachricht- > > Von: Martin Moore > > Gesendet: Sonntag, 9. Oktober 2022 09:56 > > An: Tomcat Users List ; ma...@apache.org > > Betreff: Re: About granting permissions to Tomcat JVM > > > > Hello Mark, > > > > I don't know if the SecurityManager is enabled or not (how to disable it > > btw?) > > I set the env var CATALINA_HOME to be C:/Program Files/Apache-Tomcat-8/ > > The files in question are stored in Desktop/SomeFolder > > > > Thanks. > > > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit : > > > > > On 08/10/2022 17:36, Martin Moore wrote: > > > > Hello, > > > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that deletes > > > (using > > > > file.delete() Java 8) a file from disk (Windows). The file is > > > > actually deleting only on application level meaning that the > > > > application does not see the file anymore but if i open the folder i > > > > still see the file which > > > is > > > > then locked by Java process. I only get the file to be removed > > > > physically when i close the Tomcat instance. > > > > > > > > Does this problem relate to permissions in catalina.policy ? > > > > > > Unlikely. > > > > > > Are you using a SecurityManager? > > > > > > > How to solve this? > > > > > > Where, exactly, are you storing these files? Where, exactly, are > > > CATALINA_HOME and CATALINA_BASE? > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
AW: About granting permissions to Tomcat JVM
Hello, this might be a behavior of the underlying OS. If the file is locked, it is marked for deletion and when the file lock is released, the file is physically deleted. Maybe you can check with ProcessExplorer from MS whether there is an open file handle on this file. Greetings, Thomas > -Ursprüngliche Nachricht- > Von: Martin Moore > Gesendet: Sonntag, 9. Oktober 2022 09:56 > An: Tomcat Users List ; ma...@apache.org > Betreff: Re: About granting permissions to Tomcat JVM > > Hello Mark, > > I don't know if the SecurityManager is enabled or not (how to disable it > btw?) > I set the env var CATALINA_HOME to be C:/Program Files/Apache-Tomcat-8/ > The files in question are stored in Desktop/SomeFolder > > Thanks. > > Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit : > > > On 08/10/2022 17:36, Martin Moore wrote: > > > Hello, > > > > > > I am facing a problem using Tomcat V8 with my J2ee app that deletes > > (using > > > file.delete() Java 8) a file from disk (Windows). The file is > > > actually deleting only on application level meaning that the > > > application does not see the file anymore but if i open the folder i > > > still see the file which > > is > > > then locked by Java process. I only get the file to be removed > > > physically when i close the Tomcat instance. > > > > > > Does this problem relate to permissions in catalina.policy ? > > > > Unlikely. > > > > Are you using a SecurityManager? > > > > > How to solve this? > > > > Where, exactly, are you storing these files? Where, exactly, are > > CATALINA_HOME and CATALINA_BASE? > > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: About granting permissions to Tomcat JVM
Hello Mark, I don't know if the SecurityManager is enabled or not (how to disable it btw?) I set the env var CATALINA_HOME to be C:/Program Files/Apache-Tomcat-8/ The files in question are stored in Desktop/SomeFolder Thanks. Le dim. 9 oct. 2022 à 08:00, Mark Thomas a écrit : > On 08/10/2022 17:36, Martin Moore wrote: > > Hello, > > > > I am facing a problem using Tomcat V8 with my J2ee app that deletes > (using > > file.delete() Java 8) a file from disk (Windows). The file is actually > > deleting only on application level meaning that the application does not > > see the file anymore but if i open the folder i still see the file which > is > > then locked by Java process. I only get the file to be removed physically > > when i close the Tomcat instance. > > > > Does this problem relate to permissions in catalina.policy ? > > Unlikely. > > Are you using a SecurityManager? > > > How to solve this? > > Where, exactly, are you storing these files? Where, exactly, are > CATALINA_HOME and CATALINA_BASE? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: About granting permissions to Tomcat JVM
On 08/10/2022 17:36, Martin Moore wrote: Hello, I am facing a problem using Tomcat V8 with my J2ee app that deletes (using file.delete() Java 8) a file from disk (Windows). The file is actually deleting only on application level meaning that the application does not see the file anymore but if i open the folder i still see the file which is then locked by Java process. I only get the file to be removed physically when i close the Tomcat instance. Does this problem relate to permissions in catalina.policy ? Unlikely. Are you using a SecurityManager? How to solve this? Where, exactly, are you storing these files? Where, exactly, are CATALINA_HOME and CATALINA_BASE? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
About granting permissions to Tomcat JVM
Hello, I am facing a problem using Tomcat V8 with my J2ee app that deletes (using file.delete() Java 8) a file from disk (Windows). The file is actually deleting only on application level meaning that the application does not see the file anymore but if i open the folder i still see the file which is then locked by Java process. I only get the file to be removed physically when i close the Tomcat instance. Does this problem relate to permissions in catalina.policy ? How to solve this?
RE: How to configure Tomcat 8.5.x to run in with a different windows service user, and what are minimum permissions
After a quick meeting with client this may be a moot point. On this page: https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html I saw command line references (and as I'm reviewing, it's becoming more clear that I'm not understanding use) for: -User User account used for running executable. It is used only for StartMode java or exe and enables running applications as service under account without LogonAsService privilege. --Password Password for user account set by --User parameter It looks like this is when you install the service. I was thinking that I would have to specify password somewhere. I don't think that's the case. Sorry to be a little misinformed. -Original Message- From: Mark Thomas Sent: Wednesday, June 22, 2022 10:33 AM To: users@tomcat.apache.org Subject: Re: How to configure Tomcat 8.5.x to run in with a different windows service user, and what are minimum permissions On 22/06/2022 17:02, paul@stgconsulting.com wrote: > Hello all, > > I been tasked with researching options for running Tomcat 8.5.x as a > windows service, but with a different user. > > I need to know what minimum rights for user would be, and also how to > pass user & password. I think I see how to pass user and password. I > don't see how to encrypt password though. > > Other options would be appreciated as well. Any reason running as the default (assuming a recent Tomcat version) LocalService isn't sufficiently secure? The minimum permissions would depend on the app but off the top of my head that will be at least: - file permissions as documented in the security guide - run as service - network access Exactly where are you looking to encrypt the password? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to configure Tomcat 8.5.x to run in with a different windows service user, and what are minimum permissions
On 22/06/2022 17:02, paul@stgconsulting.com wrote: Hello all, I been tasked with researching options for running Tomcat 8.5.x as a windows service, but with a different user. I need to know what minimum rights for user would be, and also how to pass user & password. I think I see how to pass user and password. I don't see how to encrypt password though. Other options would be appreciated as well. Any reason running as the default (assuming a recent Tomcat version) LocalService isn't sufficiently secure? The minimum permissions would depend on the app but off the top of my head that will be at least: - file permissions as documented in the security guide - run as service - network access Exactly where are you looking to encrypt the password? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to configure Tomcat 8.5.x to run in with a different windows service user, and what are minimum permissions
Hello all, I been tasked with researching options for running Tomcat 8.5.x as a windows service, but with a different user. I need to know what minimum rights for user would be, and also how to pass user & password. I think I see how to pass user and password. I don't see how to encrypt password though. Other options would be appreciated as well. Best, Paul
Re: File and directory permissions on Tomcat 8.5 tar archive
2017-11-24 15:53 GMT+03:00 Rune Rustand <run...@gmail.com>: > Apache Tomcat 8.5.23 > Redhat Enterprise Linux 7.4 (3.10.0-693.1.1.el7.x86_64) > > > > Binary distributions tar archive > > We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and are using > the core archive. The process is done by running a puppet script that > extracts the tar archive on all the servers (many). > > Are there any reasons why the file and directory permissions differ from > the tar archive and the zip archive? > When I unpack the tar archive the permissions on files and directories are > not set for all users. > > I unpack the archive like this: > tar zxvpf apache-tomcat-8.5.23.tar.gz > > examples of file and directories permissons are: > [runrus@nemesis apache-tomcat-8.5.23]$ ls -l > total 96 > drwxr-x---. 2 runrus runrus 4096 Nov 24 08:46 bin > drwx--. 2 runrus runrus 4096 Sep 28 12:31 conf > drwxr-x---. 2 runrus runrus 4096 Nov 24 08:46 lib > -rw-r-. 1 runrus runrus 57092 Sep 28 12:31 LICENSE > drwxr-x---. 2 runrus runrus 6 Sep 28 12:30 logs > -rw-r-. 1 runrus runrus 1723 Sep 28 12:31 NOTICE > -rw-r-. 1 runrus runrus 7064 Sep 28 12:31 RELEASE-NOTES > -rw-r-. 1 runrus runrus 15946 Sep 28 12:31 RUNNING.txt > drwxr-x---. 2 runrus runrus29 Nov 24 08:46 temp > drwxr-x---. 7 runrus runrus76 Sep 28 12:30 webapps > drwxr-x---. 2 runrus runrus 6 Sep 28 12:30 work [...] > For the zip file: > unzip apache-tomcat-8.5.23.zip > > [runrus@nemesis apache-tomcat-8.5.23]$ ls -l > total 104 > drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 bin > drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 conf > drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 lib > -rw-r--r--. 1 runrus runrus 58153 Sep 28 11:31 LICENSE > drwxr-xr-x. 2 runrus runrus 6 Sep 28 11:30 logs > -rw-r--r--. 1 runrus runrus 1774 Sep 28 11:31 NOTICE > -rw-r--r--. 1 runrus runrus 7241 Sep 28 11:31 RELEASE-NOTES > -rw-r--r--. 1 runrus runrus 16416 Sep 28 11:31 RUNNING.txt > drwxr-xr-x. 2 runrus runrus29 Sep 28 11:31 temp > drwxr-xr-x. 7 runrus runrus76 Sep 28 11:31 webapps > drwxr-xr-x. 2 runrus runrus 6 Sep 28 11:30 work Set `umask 0027` before unzipping. The 'conf' directory, the logs, and serialized sessions in 'work' are likely to contain confidential data and should not be world-readable. http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#Non-Tomcat_settings Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: File and directory permissions on Tomcat 8.5 tar archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 11/24/17 9:10 AM, Thomas Rohde wrote: > -Original message- From: Christopher Schultz > <ch...@christopherschultz.net> Sent: Friday 24th November 2017 > 14:46 To: users@tomcat.apache.org Subject: Re: AW: File and > directory permissions on Tomcat 8.5 tar archive > > > Thomas, > > On 11/24/17 8:39 AM, Thomas Rohde wrote: > > >> -Ursprüngliche Nachricht- Von: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 24. >> November 2017 14:21 An: users@tomcat.apache.org Betreff: Re: >> File and directory permissions on Tomcat 8.5 tar archive > >> Rune, > >> On 11/24/17 7:53 AM, Rune Rustand wrote: >>> Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 >>> (3.10.0-693.1.1.el7.x86_64) > > > >>> Binary distributions tar archive > >>> We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, >>> and are using the core archive. The process is done by running >>> a puppet script that extracts the tar archive on all the >>> servers (many). > >>> Are there any reasons why the file and directory permissions >>> differ from the tar archive and the zip archive? > >> Good question. Evidently, both Info-Zip (the 'unzip' program >> usually found on *NIX-based systems) and Apache Ant understand >> the Info-Zip-specified extension to the ZIP format that encodes >> file permissions and both ought to respect them when both packing >> and unpacking the archive[1]. > >> I don't know enough about the ZIP file format to be able to >> inspect the archive to determine what's actually stored in there >> (to determine if the archive lacks the permissions or if the >> extraction process is at fault). > >>> When I unpack the tar archive the permissions on files and >>> directories are not set for all users. > >>> I unpack the archive like this: tar zxvpf >>> apache-tomcat-8.5.23.tar.gz > >>> [snip] > >>> For the zip file: unzip apache-tomcat-8.5.23.zip > >>> [snip] > >> Hmm. Those definitely *should be* producing the same file >> permissions... at least, I'd expect them to produce the same >> file permissions. > >> I don't see any (missing) options to Apache ant's task >> that look like they would strip those file permissions. I also >> don't see any options for (Info-Zip) unzip that would be required >> to restore such permissions. > >> IMHO, this should Just Work. > >> -chris > >> [1] >> https://en.wikipedia.org/wiki/Zip_(file_format)#Implementation > >> - > >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> While turning around the same issue this week I compared a >> apache-tomcat-8.5.14.tar.gz and an apache-tomcat-8.0.17.tar.gz. > >> The permissions differ. > >> With 8.0.17 files have rw-r--r-- and with 8.5.14 files have >> rw-r- > >> With 8.0.17 directories (e.g. webapps) have rwxr-xr-x and with >> 8.5.14 they have rwxr-x--- > >> This means others have no permissions in current Tomcat versions >> by default. > >> I found that in the changelog of 8.5.0: Tighten up the default >> file permissions for the .tar.gz distribution so no files or >> directories are world readable by default. Configure Tomcat to >> run with a default umask of 0027 which may be overridden by >> setting UMASK in setenv.sh. (markt) > >> So I think it works like expected. > > This is a comparison of file permissions coming from tar archives > versus *zip* archives, not a comparison of file permissions coming > from (only) tar archives from two different Tomcat versions. > > -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > I know. I presumed that ZIP don't carry any file permission. So you didn't read my reply, then. > While extracting a zip file you get the permissions depending on > your umask. What makes you think that the umask doesn't apply the same way to files extracted from a zip file versus a tar file? > And that's the reason why the file permissions of an extracted zip > and and extracted tar differ. I don't think so. > The differences with Tomcat 8.0
RE: AW: File and directory permissions on Tomcat 8.5 tar archive
Chris, -Original message- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Friday 24th November 2017 14:46 To: users@tomcat.apache.org Subject: Re: AW: File and directory permissions on Tomcat 8.5 tar archive -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 11/24/17 8:39 AM, Thomas Rohde wrote: > > > -Ursprüngliche Nachricht- Von: Christopher Schultz > [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 24. > November 2017 14:21 An: users@tomcat.apache.org Betreff: Re: File > and directory permissions on Tomcat 8.5 tar archive > > Rune, > > On 11/24/17 7:53 AM, Rune Rustand wrote: >> Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 >> (3.10.0-693.1.1.el7.x86_64) > > > >> Binary distributions tar archive > >> We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and >> are using the core archive. The process is done by running a >> puppet script that extracts the tar archive on all the servers >> (many). > >> Are there any reasons why the file and directory permissions >> differ from the tar archive and the zip archive? > > Good question. Evidently, both Info-Zip (the 'unzip' program > usually found on *NIX-based systems) and Apache Ant understand the > Info-Zip-specified extension to the ZIP format that encodes file > permissions and both ought to respect them when both packing and > unpacking the archive[1]. > > I don't know enough about the ZIP file format to be able to inspect > the archive to determine what's actually stored in there (to > determine if the archive lacks the permissions or if the extraction > process is at fault). > >> When I unpack the tar archive the permissions on files and >> directories are not set for all users. > >> I unpack the archive like this: tar zxvpf >> apache-tomcat-8.5.23.tar.gz > >> [snip] > >> For the zip file: unzip apache-tomcat-8.5.23.zip > >> [snip] > > Hmm. Those definitely *should be* producing the same file > permissions... at least, I'd expect them to produce the same file > permissions. > > I don't see any (missing) options to Apache ant's task that > look like they would strip those file permissions. I also don't see > any options for (Info-Zip) unzip that would be required to restore > such permissions. > > IMHO, this should Just Work. > > -chris > > [1] https://en.wikipedia.org/wiki/Zip_(file_format)#Implementation > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > While turning around the same issue this week I compared a > apache-tomcat-8.5.14.tar.gz and an apache-tomcat-8.0.17.tar.gz. > > The permissions differ. > > With 8.0.17 files have rw-r--r-- and with 8.5.14 files have > rw-r- > > With 8.0.17 directories (e.g. webapps) have rwxr-xr-x and with > 8.5.14 they have rwxr-x--- > > This means others have no permissions in current Tomcat versions by > default. > > I found that in the changelog of 8.5.0: Tighten up the default file > permissions for the .tar.gz distribution so no files or directories > are world readable by default. Configure Tomcat to run with a > default umask of 0027 which may be overridden by setting UMASK in > setenv.sh. (markt) > > So I think it works like expected. This is a comparison of file permissions coming from tar archives versus *zip* archives, not a comparison of file permissions coming from (only) tar archives from two different Tomcat versions. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloYIo4ACgkQHPApP6U8 pFgo3hAAyjUnW8j885CPWUwffUCN++QWoRTP4qU/nV4X4P0SDrV6OZ7AN0g/ELGU klUqT6XRSaosHdxleVo4GKrP8vDg21XlezCsAZ6KclRvrtrGZ8yK0Toh+6Z4eyMc BReM/mqaiIeVhsq3BL8+gwpaYNsAxI68QGdLvYRe+wZ+AdZUXtPPQjrECC4fjFly kabmYuU37anAHOvMtGTPQWeqzLO0zPeA9GlIixKSknlzLedJ4ZkfBSOc8mBcaEcV aR08cHQyJyh/411p8o7gaWmZPR7cvUqN1/qgTd7E1ehJPhPiIi4Dz5CUD7Kw9Fa2 hzxxh9IBuJxc4ftGchltbKLZpoT9648Bt1zD3tzyAgZq0CMX3sibl7CM3v/NxxCc HYIImq9WrJlUNYactium9auDqfFNAJSW9WzTjCBWtwipcOMuW0kaCcQdJheQ6M3E /qUQ/M+A0aUgBxhZbuLy8R4Fx/wjReaSWg4pxMp9ZMwj+9XV32RlStz87vtuuww7 bosj9u4+weYpnfSnaUFrTSATFpJSus7bxzFw/nTY4+CsHiUwDt0pEAGVW/QNkCzX kgEKWEmMpzfSjQkj4/rvXTLu2aaLQrlVLcHHeADHkDt+rtUUp9h/EykNo2YaD3ca /gucCVnTU/6+doyiXLRyAjawVc9rYMeZ+N1RK1wbxgI/yGvtqqk= =XB2B -----END PGP SIGNATURE- ----- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...
Re: AW: File and directory permissions on Tomcat 8.5 tar archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 11/24/17 8:39 AM, Thomas Rohde wrote: > > > -Ursprüngliche Nachricht- Von: Christopher Schultz > [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 24. > November 2017 14:21 An: users@tomcat.apache.org Betreff: Re: File > and directory permissions on Tomcat 8.5 tar archive > > Rune, > > On 11/24/17 7:53 AM, Rune Rustand wrote: >> Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 >> (3.10.0-693.1.1.el7.x86_64) > > > >> Binary distributions tar archive > >> We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and >> are using the core archive. The process is done by running a >> puppet script that extracts the tar archive on all the servers >> (many). > >> Are there any reasons why the file and directory permissions >> differ from the tar archive and the zip archive? > > Good question. Evidently, both Info-Zip (the 'unzip' program > usually found on *NIX-based systems) and Apache Ant understand the > Info-Zip-specified extension to the ZIP format that encodes file > permissions and both ought to respect them when both packing and > unpacking the archive[1]. > > I don't know enough about the ZIP file format to be able to inspect > the archive to determine what's actually stored in there (to > determine if the archive lacks the permissions or if the extraction > process is at fault). > >> When I unpack the tar archive the permissions on files and >> directories are not set for all users. > >> I unpack the archive like this: tar zxvpf >> apache-tomcat-8.5.23.tar.gz > >> [snip] > >> For the zip file: unzip apache-tomcat-8.5.23.zip > >> [snip] > > Hmm. Those definitely *should be* producing the same file > permissions... at least, I'd expect them to produce the same file > permissions. > > I don't see any (missing) options to Apache ant's task that > look like they would strip those file permissions. I also don't see > any options for (Info-Zip) unzip that would be required to restore > such permissions. > > IMHO, this should Just Work. > > -chris > > [1] https://en.wikipedia.org/wiki/Zip_(file_format)#Implementation > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > While turning around the same issue this week I compared a > apache-tomcat-8.5.14.tar.gz and an apache-tomcat-8.0.17.tar.gz. > > The permissions differ. > > With 8.0.17 files have rw-r--r-- and with 8.5.14 files have > rw-r- > > With 8.0.17 directories (e.g. webapps) have rwxr-xr-x and with > 8.5.14 they have rwxr-x--- > > This means others have no permissions in current Tomcat versions by > default. > > I found that in the changelog of 8.5.0: Tighten up the default file > permissions for the .tar.gz distribution so no files or directories > are world readable by default. Configure Tomcat to run with a > default umask of 0027 which may be overridden by setting UMASK in > setenv.sh. (markt) > > So I think it works like expected. This is a comparison of file permissions coming from tar archives versus *zip* archives, not a comparison of file permissions coming from (only) tar archives from two different Tomcat versions. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloYIo4ACgkQHPApP6U8 pFgo3hAAyjUnW8j885CPWUwffUCN++QWoRTP4qU/nV4X4P0SDrV6OZ7AN0g/ELGU klUqT6XRSaosHdxleVo4GKrP8vDg21XlezCsAZ6KclRvrtrGZ8yK0Toh+6Z4eyMc BReM/mqaiIeVhsq3BL8+gwpaYNsAxI68QGdLvYRe+wZ+AdZUXtPPQjrECC4fjFly kabmYuU37anAHOvMtGTPQWeqzLO0zPeA9GlIixKSknlzLedJ4ZkfBSOc8mBcaEcV aR08cHQyJyh/411p8o7gaWmZPR7cvUqN1/qgTd7E1ehJPhPiIi4Dz5CUD7Kw9Fa2 hzxxh9IBuJxc4ftGchltbKLZpoT9648Bt1zD3tzyAgZq0CMX3sibl7CM3v/NxxCc HYIImq9WrJlUNYactium9auDqfFNAJSW9WzTjCBWtwipcOMuW0kaCcQdJheQ6M3E /qUQ/M+A0aUgBxhZbuLy8R4Fx/wjReaSWg4pxMp9ZMwj+9XV32RlStz87vtuuww7 bosj9u4+weYpnfSnaUFrTSATFpJSus7bxzFw/nTY4+CsHiUwDt0pEAGVW/QNkCzX kgEKWEmMpzfSjQkj4/rvXTLu2aaLQrlVLcHHeADHkDt+rtUUp9h/EykNo2YaD3ca /gucCVnTU/6+doyiXLRyAjawVc9rYMeZ+N1RK1wbxgI/yGvtqqk= =XB2B -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: File and directory permissions on Tomcat 8.5 tar archive
-Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 24. November 2017 14:21 An: users@tomcat.apache.org Betreff: Re: File and directory permissions on Tomcat 8.5 tar archive -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rune, On 11/24/17 7:53 AM, Rune Rustand wrote: > Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 > (3.10.0-693.1.1.el7.x86_64) > > > > Binary distributions tar archive > > We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and are > using the core archive. The process is done by running a puppet script > that extracts the tar archive on all the servers (many). > > Are there any reasons why the file and directory permissions differ > from the tar archive and the zip archive? Good question. Evidently, both Info-Zip (the 'unzip' program usually found on *NIX-based systems) and Apache Ant understand the Info-Zip-specified extension to the ZIP format that encodes file permissions and both ought to respect them when both packing and unpacking the archive[1]. I don't know enough about the ZIP file format to be able to inspect the archive to determine what's actually stored in there (to determine if the archive lacks the permissions or if the extraction process is at fault). > When I unpack the tar archive the permissions on files and directories > are not set for all users. > > I unpack the archive like this: tar zxvpf apache-tomcat-8.5.23.tar.gz > > [snip] > > For the zip file: unzip apache-tomcat-8.5.23.zip > > [snip] Hmm. Those definitely *should be* producing the same file permissions... at least, I'd expect them to produce the same file permissions. I don't see any (missing) options to Apache ant's task that look like they would strip those file permissions. I also don't see any options for (Info-Zip) unzip that would be required to restore such permissions. IMHO, this should Just Work. - -chris [1] https://en.wikipedia.org/wiki/Zip_(file_format)#Implementation -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloYHLMACgkQHPApP6U8 pFhIohAAmCj7pZufx9VexFHy7vl16HOdnQZ07swJ5kT4zuK29Ajv+l734Lykx0xT YGpOmjc+lYW9B8Ewz/VaqzGuH485lWK8hMNtYzv/e4nytFvI6C4D2umm/GQwefy+ 3YihUZPg0VPtw7mROYAHMYDtuPwUFbCi9Qs9rmAil+79+DIYE+RcKOuX6Da7Qbm1 xB85hHX0x2WaPbOOZh6FUcYzekMW1Nw07ggxIP7GknnnR+cWQlRo+MMufIFChCXN f0iMGN5JEkkBuFH6j0s1IYgzxUH75pa3mqIA1T5nAv0B2VRELDCBs23MOah83w6K eghMXT3eD3ti88HD7YcrC8dUzQczpNAbxsRNx5a0G2GNUVdb1u3oa/J8qUzFQrFT 5Aay5XlJgH7MYJOJxDezUojax2e372zniVaKMjhq9qKBeLoBYdCqHO/bfpkzYK9i JARpc9PVczyQYXWpcjHvlvT3OF9MSlzVZbrqdIqNHYU5lH9rhSIp9O+bRkXQpluU uEp2EeLk6rXtUdamKooW63RD1CDNjUjpXT/Hb2WrSYDrWu8gN7/1YpuNKo1nlILS aet4dePuM/6Bd1Vs1oIi21YdKvwS2lQnr/XbKjqCwe/4qAJelHRDArHFp40cLlMv B23azWYuu6kqr8aUMSXjplNTk5/i9mkYcVCUzJkN01ZZCTvPqwo= =Rk3D -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org While turning around the same issue this week I compared a apache-tomcat-8.5.14.tar.gz and an apache-tomcat-8.0.17.tar.gz. The permissions differ. With 8.0.17 files have rw-r--r-- and with 8.5.14 files have rw-r- With 8.0.17 directories (e.g. webapps) have rwxr-xr-x and with 8.5.14 they have rwxr-x--- This means others have no permissions in current Tomcat versions by default. I found that in the changelog of 8.5.0: Tighten up the default file permissions for the .tar.gz distribution so no files or directories are world readable by default. Configure Tomcat to run with a default umask of 0027 which may be overridden by setting UMASK in setenv.sh. (markt) So I think it works like expected. Regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: File and directory permissions on Tomcat 8.5 tar archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rune, On 11/24/17 7:53 AM, Rune Rustand wrote: > Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 > (3.10.0-693.1.1.el7.x86_64) > > > > Binary distributions tar archive > > We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and are > using the core archive. The process is done by running a puppet > script that extracts the tar archive on all the servers (many). > > Are there any reasons why the file and directory permissions differ > from the tar archive and the zip archive? Good question. Evidently, both Info-Zip (the 'unzip' program usually found on *NIX-based systems) and Apache Ant understand the Info-Zip-specified extension to the ZIP format that encodes file permissions and both ought to respect them when both packing and unpacking the archive[1]. I don't know enough about the ZIP file format to be able to inspect the archive to determine what's actually stored in there (to determine if the archive lacks the permissions or if the extraction process is at fault). > When I unpack the tar archive the permissions on files and > directories are not set for all users. > > I unpack the archive like this: tar zxvpf > apache-tomcat-8.5.23.tar.gz > > [snip] > > For the zip file: unzip apache-tomcat-8.5.23.zip > > [snip] Hmm. Those definitely *should be* producing the same file permissions... at least, I'd expect them to produce the same file permissions. I don't see any (missing) options to Apache ant's task that look like they would strip those file permissions. I also don't see any options for (Info-Zip) unzip that would be required to restore such permissions. IMHO, this should Just Work. - -chris [1] https://en.wikipedia.org/wiki/Zip_(file_format)#Implementation -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloYHLMACgkQHPApP6U8 pFhIohAAmCj7pZufx9VexFHy7vl16HOdnQZ07swJ5kT4zuK29Ajv+l734Lykx0xT YGpOmjc+lYW9B8Ewz/VaqzGuH485lWK8hMNtYzv/e4nytFvI6C4D2umm/GQwefy+ 3YihUZPg0VPtw7mROYAHMYDtuPwUFbCi9Qs9rmAil+79+DIYE+RcKOuX6Da7Qbm1 xB85hHX0x2WaPbOOZh6FUcYzekMW1Nw07ggxIP7GknnnR+cWQlRo+MMufIFChCXN f0iMGN5JEkkBuFH6j0s1IYgzxUH75pa3mqIA1T5nAv0B2VRELDCBs23MOah83w6K eghMXT3eD3ti88HD7YcrC8dUzQczpNAbxsRNx5a0G2GNUVdb1u3oa/J8qUzFQrFT 5Aay5XlJgH7MYJOJxDezUojax2e372zniVaKMjhq9qKBeLoBYdCqHO/bfpkzYK9i JARpc9PVczyQYXWpcjHvlvT3OF9MSlzVZbrqdIqNHYU5lH9rhSIp9O+bRkXQpluU uEp2EeLk6rXtUdamKooW63RD1CDNjUjpXT/Hb2WrSYDrWu8gN7/1YpuNKo1nlILS aet4dePuM/6Bd1Vs1oIi21YdKvwS2lQnr/XbKjqCwe/4qAJelHRDArHFp40cLlMv B23azWYuu6kqr8aUMSXjplNTk5/i9mkYcVCUzJkN01ZZCTvPqwo= =Rk3D -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
File and directory permissions on Tomcat 8.5 tar archive
Apache Tomcat 8.5.23 Redhat Enterprise Linux 7.4 (3.10.0-693.1.1.el7.x86_64) Binary distributions tar archive We are upgrading our servers from Tomcat 8.0 to Tomcat 8.5, and are using the core archive. The process is done by running a puppet script that extracts the tar archive on all the servers (many). Are there any reasons why the file and directory permissions differ from the tar archive and the zip archive? When I unpack the tar archive the permissions on files and directories are not set for all users. I unpack the archive like this: tar zxvpf apache-tomcat-8.5.23.tar.gz examples of file and directories permissons are: [runrus@nemesis apache-tomcat-8.5.23]$ ls -l total 96 drwxr-x---. 2 runrus runrus 4096 Nov 24 08:46 bin drwx--. 2 runrus runrus 4096 Sep 28 12:31 conf drwxr-x---. 2 runrus runrus 4096 Nov 24 08:46 lib -rw-r-. 1 runrus runrus 57092 Sep 28 12:31 LICENSE drwxr-x---. 2 runrus runrus 6 Sep 28 12:30 logs -rw-r-. 1 runrus runrus 1723 Sep 28 12:31 NOTICE -rw-r-. 1 runrus runrus 7064 Sep 28 12:31 RELEASE-NOTES -rw-r-. 1 runrus runrus 15946 Sep 28 12:31 RUNNING.txt drwxr-x---. 2 runrus runrus29 Nov 24 08:46 temp drwxr-x---. 7 runrus runrus76 Sep 28 12:30 webapps drwxr-x---. 2 runrus runrus 6 Sep 28 12:30 work [runrus@nemesis apache-tomcat-8.5.23]$ ls -l lib total 7644 -rw-r-. 1 runrus runrus 18254 Sep 28 12:30 annotations-api.jar -rw-r-. 1 runrus runrus 54300 Sep 28 12:30 catalina-ant.jar -rw-r-. 1 runrus runrus 119087 Sep 28 12:30 catalina-ha.jar -rw-r-. 1 runrus runrus 1623570 Sep 28 12:30 catalina.jar -rw-r-. 1 runrus runrus 75103 Sep 28 12:30 catalina-storeconfig.jar -rw-r-. 1 runrus runrus 281816 Sep 28 12:30 catalina-tribes.jar -rw-r-. 1 runrus runrus 2450404 Sep 28 12:30 ecj-4.6.3.jar -rw-r-. 1 runrus runrus 81361 Sep 28 12:30 el-api.jar -rw-r-. 1 runrus runrus 163295 Sep 28 12:30 jasper-el.jar -rw-r-. 1 runrus runrus 592050 Sep 28 12:30 jasper.jar -rw-r-. 1 runrus runrus 26863 Sep 28 12:30 jaspic-api.jar -rw-r-. 1 runrus runrus 61756 Sep 28 12:30 jsp-api.jar -rw-r-. 1 runrus runrus 244134 Sep 28 12:30 servlet-api.jar -rw-r-. 1 runrus runrus 10562 Sep 28 12:30 tomcat-api.jar -rw-r-. 1 runrus runrus 788380 Sep 28 12:30 tomcat-coyote.jar -rw-r-. 1 runrus runrus 251940 Sep 28 12:30 tomcat-dbcp.jar -rw-r-. 1 runrus runrus 66928 Sep 28 12:30 tomcat-i18n-es.jar -rw-r-. 1 runrus runrus 40824 Sep 28 12:30 tomcat-i18n-fr.jar -rw-r-. 1 runrus runrus 42130 Sep 28 12:30 tomcat-i18n-ja.jar -rw-r-. 1 runrus runrus 144981 Sep 28 12:30 tomcat-jdbc.jar -rw-r-. 1 runrus runrus 34543 Sep 28 12:30 tomcat-jni.jar -rw-r-. 1 runrus runrus 136560 Sep 28 12:30 tomcat-util.jar -rw-r-. 1 runrus runrus 205365 Sep 28 12:30 tomcat-util-scan.jar -rw-r-. 1 runrus runrus 217108 Sep 28 12:30 tomcat-websocket.jar -rw-r-. 1 runrus runrus 36947 Sep 28 12:30 websocket-api.jar For the zip file: unzip apache-tomcat-8.5.23.zip [runrus@nemesis apache-tomcat-8.5.23]$ ls -l total 104 drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 bin drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 conf drwxr-xr-x. 2 runrus runrus 4096 Sep 28 11:31 lib -rw-r--r--. 1 runrus runrus 58153 Sep 28 11:31 LICENSE drwxr-xr-x. 2 runrus runrus 6 Sep 28 11:30 logs -rw-r--r--. 1 runrus runrus 1774 Sep 28 11:31 NOTICE -rw-r--r--. 1 runrus runrus 7241 Sep 28 11:31 RELEASE-NOTES -rw-r--r--. 1 runrus runrus 16416 Sep 28 11:31 RUNNING.txt drwxr-xr-x. 2 runrus runrus29 Sep 28 11:31 temp drwxr-xr-x. 7 runrus runrus76 Sep 28 11:31 webapps drwxr-xr-x. 2 runrus runrus 6 Sep 28 11:30 work [runrus@nemesis apache-tomcat-8.5.23]$ ls -l lib total 7644 -rw-r--r--. 1 runrus runrus 18254 Sep 28 11:31 annotations-api.jar -rw-r--r--. 1 runrus runrus 54300 Sep 28 11:31 catalina-ant.jar -rw-r--r--. 1 runrus runrus 119087 Sep 28 11:31 catalina-ha.jar -rw-r--r--. 1 runrus runrus 1623570 Sep 28 11:31 catalina.jar -rw-r--r--. 1 runrus runrus 75103 Sep 28 11:31 catalina-storeconfig.jar -rw-r--r--. 1 runrus runrus 281816 Sep 28 11:31 catalina-tribes.jar -rw-r--r--. 1 runrus runrus 2450404 Sep 28 11:31 ecj-4.6.3.jar -rw-r--r--. 1 runrus runrus 81361 Sep 28 11:31 el-api.jar -rw-r--r--. 1 runrus runrus 163295 Sep 28 11:31 jasper-el.jar -rw-r--r--. 1 runrus runrus 592050 Sep 28 11:31 jasper.jar -rw-r--r--. 1 runrus runrus 26863 Sep 28 11:31 jaspic-api.jar -rw-r--r--. 1 runrus runrus 61756 Sep 28 11:31 jsp-api.jar -rw-r--r--. 1 runrus runrus 244134 Sep 28 11:31 servlet-api.jar -rw-r--r--. 1 runrus runrus 10562 Sep 28 11:31 tomcat-api.jar -rw-r--r--. 1 runrus runrus 788380 Sep 28 11:31 tomcat-coyote.jar -rw-r--r--. 1 runrus runrus 251940 Sep 28 11:31 tomcat-dbcp.jar -rw-r--r--. 1 runrus runrus 66928 Sep 28 11:31 tomcat-i18n-es.jar -rw-r--r--. 1 runrus runrus 40824 Sep 28 11:31 tomcat-i18n-fr.jar -rw-r--r--. 1 runrus runrus 42130 Sep 28 11:31 tomcat-i18n-ja.jar
Re: Tomcat log files - Strict permissions - setuid
On Thu, Dec 03, 2015 at 10:42:40AM -0300, Andres Riancho wrote: > List, > > I'm trying to secure my tomcat instances. One of the steps I took > was to run the tomcat process using the non-privileged "tomcat" user, > and set the file system permissions as restrictive as possible. It all > works well, but there is something missing: "The tomcat user is able > to read the access log files": > > root@7083cdc8e2fc:/apps/tomcat/logs# ls -la > ... > -rw-rw 1 tomcat tomcat0 Dec 1 19:46 > 0.0.0.0_access_log.2015-12-01.txt One fancier approach would be to configure a log sink which passes records to another process through a socket -- syslog, for example. There are syslog Handler implementations for java.util.logging, or you could cook up a custom log recorder to receive from the stock j.u.l.SocketHandler, or you could configure Tomcat to use slf4j/logback and its syslog appender. This will not be simple but it will be quite adaptable. You should probably look at simpler methods first. > Is there any way to configure tomcat to be able to write to the > access log file, but have the file owned by root with permissions 600? > I understand that this is done by starting the tomcat process as root > and then dropping privileges using setuid() , but was unable to find > something already built / well documented. That is what the Commons Daemon tool (jsvc) is for. That should be a lot simpler. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature
Re: Tomcat log files - Strict permissions - setuid
Andres, On 12/3/15 8:42 AM, Andres Riancho wrote: > List, > > I'm trying to secure my tomcat instances. One of the steps I took > was to run the tomcat process using the non-privileged "tomcat" user, > and set the file system permissions as restrictive as possible. It all > works well, but there is something missing: "The tomcat user is able > to read the access log files": > > root@7083cdc8e2fc:/apps/tomcat/logs# ls -la > ... > -rw-rw 1 tomcat tomcat0 Dec 1 19:46 > 0.0.0.0_access_log.2015-12-01.txt > > Is there any way to configure tomcat to be able to write to the > access log file, but have the file owned by root with permissions 600? > I understand that this is done by starting the tomcat process as root > and then dropping privileges using setuid() , but was unable to find > something already built / well documented. How do you launch Tomcat? If you use the scripts, you could use something like bin/setenv.sh to check the permissions of the log files and refuse to start if they aren't the way you want them. For files that don't already exist, you'll have to refuse to start if they don't exist, because a process can't create a new file owned by another user. You'd have to disable file-rotation because of the same problem. Are you more worried about a hostile web application running within your server, a hostile remote user, a vulnerability in a web application, or a vulnerability in Tomcat? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat log files - Strict permissions - setuid
List, I'm trying to secure my tomcat instances. One of the steps I took was to run the tomcat process using the non-privileged "tomcat" user, and set the file system permissions as restrictive as possible. It all works well, but there is something missing: "The tomcat user is able to read the access log files": root@7083cdc8e2fc:/apps/tomcat/logs# ls -la ... -rw-rw 1 tomcat tomcat0 Dec 1 19:46 0.0.0.0_access_log.2015-12-01.txt Is there any way to configure tomcat to be able to write to the access log file, but have the file owned by root with permissions 600? I understand that this is done by starting the tomcat process as root and then dropping privileges using setuid() , but was unable to find something already built / well documented. Ideas? Regards, -- Andrés Riancho Project Leader at w3af - http://w3af.org/ Web Application Attack and Audit Framework Twitter: @w3af GPG: 0x93C344F3 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-13 12:03 PM, André Warnier wrote: On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Personally, I don't think you should. The scary thing here is All newly created files. That means e.g. all webapps deployed by Tomcat, not just your my_webapp. But if you wanted to do it nevertheless, under Linux you would do that in the /etc/init.d script which starts Tomcat. Ok. Thank you. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. In the possible consequences, it is quite similar, no ? or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? I wasn't thinking about any auditing software in particular. But most of them will scan the permissions of a set of well-know directories (and tomcat/webapps would be one of those) and flag anything that they consider suspicious or non-standard. By the Java Servlet Specification, the webapps directories would not normally be writeable, so this may come up. Which, in the best of cases, would result in you having to write a report describing why you needed to set the permissions that way. Which is probably not the kind of thing at which you want to spend your time. But maybe your company does not do this kind of audit, in which case all that is irrelevant. I just wanted to warn you of the possibility. I do actually have a couple of customers where this would be a definite no-no. (There is also the possibility of a colleague of yours, seeing those permissions in 6 months time while you are on holiday, and re-setting them properly..) Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. Rules can be broken, if there is enough justification. What I meant was that strictly going by the rules, making your webapp's directory writeable is not something which you should be doing, because in theory this is not something which you can always expect to be possible. You have now described your context in more detail, and now we know that this is not an application which you would distribute to work on some kind of mobile device where it would be stored on some non-writeable ROM device. But before the latest explanation, we did not know that. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Right. In your particular context and as you describe it above, it does not seem that it would hurt. Please understand that we still don't know exactly the whole practical context in which all of this lives. For example, we do not know if what you are trying to achieve is some kind of website where users can upload their own HTML pages, or whether this is some kind of repository where users can upload office documents to share between them, or if you are trying to replace Sharepoint as a collaborative tool, or whatever. Nor do we know if this has
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-14 12:45 PM, André Warnier wrote: Lmhelp1 wrote: On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. In the possible consequences, it is quite similar, no ? or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? I wasn't thinking about any auditing software in particular. But most of them will scan the permissions of a set of well-know directories (and tomcat/webapps would be one of those) and flag anything that they consider suspicious or non-standard. By the Java Servlet Specification, the webapps directories would not normally be writeable, so this may come up. Which, in the best of cases, would result in you having to write a report describing why you needed to set the permissions that way. Which is probably not the kind of thing at which you want to spend your time. But maybe your company does not do this kind of audit, in which case all that is irrelevant. I just wanted to warn you of the possibility. I do actually have a couple of customers where this would be a definite no-no. (There is also the possibility of a colleague of yours, seeing those permissions in 6 months time while you are on holiday, and re-setting them properly..) Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. Rules can be broken, if there is enough justification. What I meant was that strictly going by the rules, making your webapp's directory writeable is not something which you should be doing, because in theory this is not something which you can always expect to be possible. You have now described your context in more detail, and now we know that this is not an application which you would distribute to work on some kind of mobile device where it would be stored on some non-writeable ROM device. But before the latest explanation, we did not know that. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Right. In your particular context and as you describe it above, it does not seem that it would hurt. Please understand that we still don't know exactly the whole practical context in which all of this lives. For example, we do not know if what you are trying to achieve is some kind of website where users can upload their own HTML pages, or whether this is some kind of repository where users can upload office documents to share between them, or if you are trying to replace Sharepoint as a collaborative tool, or whatever. Nor do we know
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-12 11:32 PM, André Warnier [via Tomcat] wrote: Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. That's it, I only miss the write permission for the owner group which is tomcat6. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. Ok. This is what I was looking for. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). For now, I do a chmod g+w my_webapp manually. One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Yes, indeed. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. I see. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. I see. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify this, I have never used aliases under Tomcat and I do not really know if that would be usable here). The one solution which gives you the most control is the one where your own my_webapp webapp is the one which actually reads and returns the files to the browser, because that is your code, and you can bend it in any way you want. (Including for example, returning something nice to the client, when the file that he wants is not there). Another time maybe :). Be careful that changing the permissions of your webapps/my_webapp directory itself, may weaken the security of your Tomcat website, because there may be other things in there than the files which you intend to serve to the clients. That's why having these files somewhere else than directly under webapps/my_webapp may be preferable in any case
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Hello and thank you for your answer. On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Who is placing these files into the webapp folder? I am manually placing my_webapp.war in the Tomcat6 webapps folder. Best regards. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-12 11:32 PM, André Warnier [via Tomcat] wrote: Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. That's it, I only miss the write permission for the owner group which is tomcat6. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. Ok. This is what I was looking for. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). For now, I do a chmod g+w my_webapp manually. One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Yes, indeed. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. I see. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. I see. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify this, I have never used aliases under Tomcat and I do not really know if that would be usable here). The one solution which gives you the most control is the one where your own my_webapp webapp is the one which actually reads and returns the files to the browser, because that is your code, and you can bend it in any way you want. (Including for example, returning something nice to the client, when the file that he wants is not there). Another time maybe :). Be careful that changing the permissions of your webapps/my_webapp directory itself, may weaken the security of your Tomcat website, because there may be other things in there than the files which you intend to serve to the clients. That's why having these files somewhere else than directly under webapps/my_webapp may be preferable
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Personally, I don't think you should. The scary thing here is All newly created files. That means e.g. all webapps deployed by Tomcat, not just your my_webapp. But if you wanted to do it nevertheless, under Linux you would do that in the /etc/init.d script which starts Tomcat. Who is placing these files into the webapp folder? I am manually placing my_webapp.war in the Tomcat6 webapps folder. Best regards. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-11 7:44 PM, André Warnier [via Tomcat] wrote: Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. Hello, Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. (I'm not sure that I completely understand this sentence.) Yet, thank you for the advice about adding the user lmhelp1 to the group tomcat6. That's a good idea but tomcat6, as a the owner group of the files that are created, doesn't have the write permission by default on these files... I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-11 7:44 PM, André Warnier [via Tomcat] wrote: Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. Hello, Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. (I'm not sure that I completely understand this sentence.) Yet, thank you for the advice about adding the user lmhelp1 to the group tomcat6. That's a good idea but tomcat6, as a the owner group of the files that are created, doesn't have the write permission by default on these files... If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). To be able to delete a file, you need write permission to the directory where the file resides (and not necessarily to the file). Moving or deleting a file, is an operation which changes the content of the directory containing the file. It does not modify the file itself, so you do not need write permission to the file. So, since you have access to the code of the upload webapp, you can decide in which directory it writes the uploaded files. And since you have full control of the system, you can set the permissions of that upload directory as you wish them to be. So if you set the upload directory to belong to user tomcat6, and to have write permission for the group (tomcat6), and you add your own user-id to the group tomcat6, then you should be able, under your own login, to move and/or delete these files (independently of the permissions of the files themselves). I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). That is interesting, but it implies that you have modified the standard user tomcat6 in such a way that it now has a shell when it logs in. By default, this user would have been created with /bin/false as a shell entry (in /etc/passwd). That would prevent a shell login as that user, and it is a security feature. It normally prevents anyone who has managed to take control of your Tomcat server (though a malicious or buggy webapp e.g.), to easily obtain a shell and being able to execute any command on your server through such a shell. By changing this, you weaken the security of your system. In your particular case, it may not matter very much. But in the general case, that is not a good thing. Remember that a hacker which gains access to your server, cannot only do damage to your server. He can use your server as a platform to do damage to other servers, making it look like it is your server doing it. Example: your webapp allows users to upload files to your server. How does your webapp handle the file names, for the files that the user uploads ? Do you use the original filename that the user provides ? If yes, are you filtering this filename for characters that may have a meaning for a shell (like | or or or etc..) ? Regarding ACls : under Linux, the usage of setfacl and siblings is kind of a dark art, reserved to wizards of the 3rd level and up. I know relatively little about them, but one thing which I think that I remember, is that you must enable ACLs on the filesystem in which you want to use them, in the command that mounts that filesystem. Maybe that is what was missing in your case ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. In my case, the target directory is the webapp directory my_webapp. This directory is created when tomcat6 deploys the archive my_webapp.war which I put into the Tomcat webapps container. By default, the owner of this directory is tomcat6, the owner group is tomcat6 and the permissions are 755. So as you see, unfortunately, the owner group doesn't have the write permission :/ To be able to delete a file, you need write permission to the directory where the file resides (and not necessarily to the file). Moving or deleting a file, is an operation which changes the content of the directory containing the file. It does not modify the file itself, so you do not need write permission to the file. So, since you have access to the code of the upload webapp, you can decide in which directory it writes the uploaded files. And since you have full control of the system, you can set the permissions of that upload directory as you wish them to be. Yes indeed. There are no problems with the source directory. So if you set the upload directory to belong to user tomcat6, and to have write permission for the group (tomcat6), and you add your own user-id to the group tomcat6, then you should be able, under your own login, to move and/or delete these files (independently of the permissions of the files themselves). That would be perfect if we were not talking about the source directory but about the target directory... What I actually do is copy manually (using WinSCP and logged into WinSCP as user1) a file that was uploaded by the webapp into what you call the upload directory (source directory) into the webapp root directory namely my_webapp (target directory). (I hope this sentence is clear enough :)) As you suggested (and which is a good idea), I added my user id, say user1 to the group tomcat6. Yet I'm lacking the write permission for the owner group of the target directory (my_webapp). Maybe there is a way to tell the process which deployed the webapp (tomcat6, java?) to enable the write permission for the root directory of a deployed webapp and for its owner group ? I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). That is interesting, but it implies that you have modified the standard user tomcat6 in such a way that it now has a shell when it logs in. By default, this user would have been created with /bin/false as a shell entry (in /etc/passwd). That would prevent a shell login as that user, and it is a security feature. It normally prevents anyone who has managed to take control of your Tomcat server (though a malicious or buggy webapp e.g.), to easily obtain a shell and being able to execute any command on your server through such a shell. By changing this, you weaken the security of your system. In your particular case, it may not matter very much. But in the general case, that is not a good thing. Remember that a hacker which gains access to your server, cannot only do damage to your server. He can use your server as a platform to do damage to other servers, making it look like it is your server doing it. Example: your webapp allows users to upload files to your server. How does your webapp handle the file names, for the files that the user uploads ? Do you use the original filename that the user provides ? If yes, are you filtering this filename for characters that may have a meaning for a shell (like | or or or etc..) ? Ah ok. Indeed, I replaced /bin/false with /bin/bash in /etc/passwd for the user tomcat6. I just reverted this since you wisely advise and explain why not to do it :) Regarding ACls : under Linux, the usage of setfacl and siblings is kind of a dark art, reserved to wizards of the 3rd level and up. I know relatively little about them, but one thing which I think that I remember, is that you must enable ACLs on the filesystem in which you want to use them, in the command that mounts that filesystem. Maybe that is what was missing in your case? I actually went to /etc/fstab and added the option acl for the partition /home. So setfacl works for me. Thank you. Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. In my case, the target directory is the webapp directory my_webapp. This directory is created when tomcat6 deploys the archive my_webapp.war which I put into the Tomcat webapps container. By default, the owner of this directory is tomcat6, the owner group is tomcat6 and the permissions are 755. So as you see, unfortunately, the owner group doesn't have the write permission :/ Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On Mar 12, 2014 11:31 PM, André Warnier a...@ice-sa.com wrote: Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Who is placing these files into the webapp folder?
Files created by a Tomcat webapp and owner, owner group, permissions for this file
-- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. Best regards. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 3/11/14, 12:31 PM, Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. You can set the file permissions (bits) by setting the umask of the process. When creating files, the process uid and gid are used as defaults for ownership. If you want to use user1 and group1, then you should run Tomcat under those uid and gid settings. I'm unaware of any setting which will allow a process to run under one uid but files created by that process are owned by another user. You might be able to get away with a cron process that re-assigns ownership of the files periodically. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTH0RgAAoJEBzwKT+lPKRYehAQAIYB0YNPWaB0vqjjlDS42adl KCmU6dj3CnGfw4I+4b4yLymAdixrv1Y0tuLGvXwWIznUZChhGaL2tVYTacuzO2yt mwipWy5OIBKchFCxjlL0SsSEfx3OFQ7sbDQuxwHW9wpq1MkqnNXWtv0VhKi7Q9cf A6JAyJIs4lOHO79KDtYRU+ckB3lT0CynlQGR0xKevdF6CaLE8EHYsAV8YMJhM07p kPdH1W3UXS6ta3QGybDbVe2ED5WuuWoCJoitavJgocNaOjBkoNzOv8Fyrfn0pvFQ m6A0Rm+W5apt2kseb1o63COlka8/jV7Bx8BxEiQEzZ29apGb5tc7tflI6c3n6e/H Hgy4YrZpUrWkH6Aa4NCwyiqzFgcsob1uFBTACnR5+imXiEYX9acqJtJSmc2qdcbF Ye7OFxyncsH3wvcXwXabJjqakBqFZ85BMizZ4XKRptnOvXOh5rr4K03LdDyqXExn ufrLvCGWIb1lofhCbqbCK0OQp68minoiEmyi98n9S+9vwfvonG5cUdPNmBpLu2r4 DTEnPnI6w75nvxv7ATdTKFq7AgR0ftJvwqunazFaODLPgadP57q4FEqI38yglrIK KKBd4xF8HmeV1D+Viqo2OD9NKZX24llFQwVT7v4vXMf+/1SJgnw1uqZJhSCDnVsM STJCNdoHG2z32H/hgb7z =gIgR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. The other thing is : do you have the code of that webapp and could you change it ? And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Thank you for your answers. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). Yes indeed. That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. Yes, it looks like this is it. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. All right, I won't do this then. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. Thank you, I understand. But I'm not going to do this either. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. I do have full access to the server... I'm interested in this solution but I couldn't find a way to force the file owner, owner group and permissions for a given directory using setfacl. I know this forum is not about ACLs but can you assist me on doing this? The other thing is : do you have the code of that webapp and could you change it ? Yes, I can. And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? The other process is me :) The webapp stores files in a directory. I, as a human, check these files. And when I'm ready, I put them manually in another directory (in the WebContent directory of the webapp to be more precise). I just do not want to put the files directly online. Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. Yes, well, if I log in as tomcat6, it will work. Best regards, -- Léa On 2014-03-11 6:16 PM, André Warnier wrote: Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. The other thing is : do you have the code of that webapp and could you change it ? And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: ... The other thing is : do you have the code of that webapp and could you change it ? Yes, I can. And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? The other process is me :) The webapp stores files in a directory. I, as a human, check these files. And when I'm ready, I put them manually in another directory (in the WebContent directory of the webapp to be more precise). I just do not want to put the files directly online. Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. Yes, well, if I log in as tomcat6, it will work. Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting log file permissions upon creation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/17/13, 11:29 AM, Mark Eggers wrote: There are not a lot of files that Tomcat creates. 1. log files, as we have been discussing 2. PID file - if enabled, and that depends on where you write it 3. serialized sessions 4. JSP files - generate a .java file and the corresponding class 5. looks like some Maven stuff may get unpacked in the work directory Tomcat does not use Maven for anything, so I think #5 may be environment-specific. 6. For servlet-3.0-style uploads, Tomcat will write uploaded files temporarily to the disk (in the work/ directory?) once they exceed the configured maximum threshold. OP might want to read the man page for sticky which documents the sticky bit for directories. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSsdvyAAoJEBzwKT+lPKRYaHIQALs/8WfZJ1R7I21E0Ixdqj4c 70XVQ/9zsLZNODzX03W0cSHidb+DhJN3eQU+oRdyorDbPaqXQLYcs+XLjjA10SZp DZzt/Z9TVPh8ZnzfdHl9zpo/STR6s1pF64ZwXxG3MvLGA5PELkAAkXqCHE7y8cFk JD5022UZpkEIopqsen8hchXblqyPXpaV9JCc39SUhJGbhnJAi3kgJTzW1VjegD7+ kEAnhdKDCtkYrG9RW+xsvIDIpCeZFWkM6bvUuKHov5MNiIWh/M+wMj+BX9vWp4w7 Q+zVi37e7wgg5ndnWo4sg9QuCSnlMEmJjICflq2+JQ+Y7VkpCQV5J5jcIMlRULq0 zQqIGn0L3Q25TawPExVOu1kTn4PCOlK6P6nZq0h1bikyqXYXtyxxln638wk8MHkC ZkirM/cQCLqTiyFE3ydU9Kg8mHxAIsJuazbHVMJGSFVFZURlbFeH35nG0suwZjJI WYon/H4sDtTC0EMsfYH4NSoN9u/UgJbZYBJap66JDXGZogQBEMH9ubUqcUGIHLHG 8DUPi+q9aPaaNivDaoeD8zOLRbrTi6sfrAiZNHGtkRf3eaMEXJ35XBIWPhNXh6gl I8wUJFXTBDj69YZd1ZsINzucVU82G6/1756jGkA2fk8SrPTItiu6NdsMbypIK9cN tQU8bEpdRzNmEzNtJuY3 =jg3c -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting log file permissions upon creation?
On Mon, Dec 16, 2013 at 10:25 PM, Mark Eggers its_toas...@yahoo.com wrote: Inline response: This is true, but shouldn't be a problem. If you're running on a system that has ACL, then you could try the following: cd $CATALINA_BASE setfacl -n -d -m u::rwx,g::rx,o::- logs Read the setfacl / getfacl manual pages for more info. To restore (remove the access control lists), run the following: cd $CATALINA_BASE setfacl -b logs . . . just my two cents /mde/ Hey Mark, So the ACL option is a no-go. I'm willing to try your earlier suggestion of the setenv.sh script, however I'm not sure what files Tomcat creates other than log files and PID files that creating this script would affect. Do you have any insight into that? Appreciate all the help! Chris
Re: Setting log file permissions upon creation?
On 12/17/2013 4:39 AM, Chris Wise wrote: On Mon, Dec 16, 2013 at 10:25 PM, Mark Eggers its_toas...@yahoo.com wrote: Inline response: This is true, but shouldn't be a problem. If you're running on a system that has ACL, then you could try the following: cd $CATALINA_BASE setfacl -n -d -m u::rwx,g::rx,o::- logs Read the setfacl / getfacl manual pages for more info. To restore (remove the access control lists), run the following: cd $CATALINA_BASE setfacl -b logs . . . just my two cents /mde/ Hey Mark, So the ACL option is a no-go. I'm willing to try your earlier suggestion of the setenv.sh script, however I'm not sure what files Tomcat creates other than log files and PID files that creating this script would affect. Do you have any insight into that? Appreciate all the help! Chris Chris, There are not a lot of files that Tomcat creates. 1. log files, as we have been discussing 2. PID file - if enabled, and that depends on where you write it 3. serialized sessions 4. JSP files - generate a .java file and the corresponding class 5. looks like some Maven stuff may get unpacked in the work directory I believe the serialized sessions go in java.io.tmpdir, which is normally set to $CATALINA_BASE/temp. The JSP files (.jsp, .java, .class) end up in $CATALINA_BASE/work/[Engine]/[Host], where [Engine] and [Host] are from the Engine and Host elements in your server.xml. This leaves out the biggest offender of them all - applications. An application could write files out to specified directories (think file uploading) which then get processed by other external applications. If you do this, then potentially any external application will no longer be able to manipulate those files. Only you know your applications, so testing is obviously in order here. You haven't said much about your environment, so I don't know what other impact this will cause. Did you install Tomcat from tomcat.apache.org, or from a distribution? If you installed Tomcat from a distribution repackaging, components get scattered everywhere, and the umask trick may cause some problems. Are you running on an ext3 or ext4 file system? For an ext3-based system, you can remount a file system to enable ACL. ACL is enabled by default on ext4. Of course if you're running on a cloud platform, you may have less control over this. . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Setting log file permissions upon creation?
Hi, I’m wondering if there is a way to force Tomcat to set permissions on log files when they’re created? It seems as though this would be something defined in the logging.properties file, but it doesn’t seem like it’s an option. I want the permissions of all log files created (on server startup/log rollover) to be 640. The only way I can think of doing this is either adding the command to the startup script, or by running a cron job every hour or so. However, if there is a way to make sure the log files are never more permissive than 640, that would be greatly preferable. Thank you, Chris
Re: Setting log file permissions upon creation?
On 12/16/2013 4:04 PM, Chris Wise wrote: Hi, I’m wondering if there is a way to force Tomcat to set permissions on log files when they’re created? It seems as though this would be something defined in the logging.properties file, but it doesn’t seem like it’s an option. I want the permissions of all log files created (on server startup/log rollover) to be 640. The only way I can think of doing this is either adding the command to the startup script, or by running a cron job every hour or so. However, if there is a way to make sure the log files are never more permissive than 640, that would be greatly preferable. Thank you, Chris 1. Create a setenv.sh file in $CATALINA_BASE/bin. 2. Add the following: #!/bin/bash umask 0026 Seems to work for me - quickly tested on Fedora 19, Tomcat 7.0.42, JRE 1.7.0_45. . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting log file permissions upon creation?
Hey Mark, Thanks for the response :) Just a quick question - won't this make ALL files Tomcat creates the same permissive...ness? Instead of just the log files? Thanks again! On Mon, Dec 16, 2013 at 7:25 PM, Mark Eggers its_toas...@yahoo.com wrote: On 12/16/2013 4:04 PM, Chris Wise wrote: Hi, I’m wondering if there is a way to force Tomcat to set permissions on log files when they’re created? It seems as though this would be something defined in the logging.properties file, but it doesn’t seem like it’s an option. I want the permissions of all log files created (on server startup/log rollover) to be 640. The only way I can think of doing this is either adding the command to the startup script, or by running a cron job every hour or so. However, if there is a way to make sure the log files are never more permissive than 640, that would be greatly preferable. Thank you, Chris 1. Create a setenv.sh file in $CATALINA_BASE/bin. 2. Add the following: #!/bin/bash umask 0026 Seems to work for me - quickly tested on Fedora 19, Tomcat 7.0.42, JRE 1.7.0_45. . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting log file permissions upon creation?
Inline response: On 12/16/2013 6:06 PM, Chris Wise wrote: Hey Mark, Thanks for the response :) Just a quick question - won't this make ALL files Tomcat creates the same permissive...ness? Instead of just the log files? This is true, but shouldn't be a problem. If you're running on a system that has ACL, then you could try the following: cd $CATALINA_BASE setfacl -n -d -m u::rwx,g::rx,o::- logs Read the setfacl / getfacl manual pages for more info. To restore (remove the access control lists), run the following: cd $CATALINA_BASE setfacl -b logs . . . just my two cents /mde/ Thanks again! On Mon, Dec 16, 2013 at 7:25 PM, Mark Eggers its_toas...@yahoo.com wrote: On 12/16/2013 4:04 PM, Chris Wise wrote: Hi, I’m wondering if there is a way to force Tomcat to set permissions on log files when they’re created? It seems as though this would be something defined in the logging.properties file, but it doesn’t seem like it’s an option. I want the permissions of all log files created (on server startup/log rollover) to be 640. The only way I can think of doing this is either adding the command to the startup script, or by running a cron job every hour or so. However, if there is a way to make sure the log files are never more permissive than 640, that would be greatly preferable. Thank you, Chris 1. Create a setenv.sh file in $CATALINA_BASE/bin. 2. Add the following: #!/bin/bash umask 0026 Seems to work for me - quickly tested on Fedora 19, Tomcat 7.0.42, JRE 1.7.0_45. . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 404 - Might there be something wrong with my permissions?
2013/11/21 Fredrik Andersson fredan...@hotmail.com: Hello Tomcat-experts! It is hard to read you message. I have recently bought some space at a webhotel that uses Apache HTTP server as front before a Tomcat 6.0.37.My account at the webhotel is said to support Struts and Hibernate and such technics.At home I have developed a app that uses those technics and of course it runs fine in a similar environment as the one at the webhotel. I can deploy my app as a ROOT-app or a ordinary app and the Struts works perfectly. At the webhotel I have tried to deploy it booth as a ROOT-app and as a MYAPP-webapp-1.0.0.war-file Now I have stripped the app down to just a struts2-hello-world-app. But at the webhotel I just keep getting this when I try to access the ActionClass through struts.xml: HTTP Status 404 - There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].type Status reportmessage There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].description The requested resource is not available. Unfortenatly the support guys at the webhotel says they lack knowledge of Tomcat so they can not help me out. If you want to change your hosting provider, there are a number of offers at http://wiki.apache.org/tomcat/PoweredBy#Hosting_providers But today I at least found this exception in the catalina.log just after my attempt yo access a struts-path: /-- Encapsulated exception \ java.lang.NullPointerException: permission can't be null at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:834) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1280) at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1481) at ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85) at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:162) at com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:77) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at ognl.ASTProperty.setValueBody(ASTProperty.java:127) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220) at ognl.SimpleNode.setValue(SimpleNode.java:301) at ognl.Ognl.setValue(Ognl.java:737) at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:217) at com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:186) at com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:173) at com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:151) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:292) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:203) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:211) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:190) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:75) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:90) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:243) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:100) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:141) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at
RE: 404 - Might there be something wrong with my permissions?
Hello Konstantin!Thanks for your reply!Yes the message got really hard to read, it looked fine when I send it!My apologies for that!I will start to investigate your advice right away!Sounds really interesting!I will get back as soon I got any new info!Best regards and thanks alot again!/Fredrik Date: Thu, 21 Nov 2013 17:10:58 +0400 Subject: Re: 404 - Might there be something wrong with my permissions? From: knst.koli...@gmail.com To: users@tomcat.apache.org 2013/11/21 Fredrik Andersson fredan...@hotmail.com: Hello Tomcat-experts! It is hard to read you message. I have recently bought some space at a webhotel that uses Apache HTTP server as front before a Tomcat 6.0.37.My account at the webhotel is said to support Struts and Hibernate and such technics.At home I have developed a app that uses those technics and of course it runs fine in a similar environment as the one at the webhotel. I can deploy my app as a ROOT-app or a ordinary app and the Struts works perfectly. At the webhotel I have tried to deploy it booth as a ROOT-app and as a MYAPP-webapp-1.0.0.war-file Now I have stripped the app down to just a struts2-hello-world-app. But at the webhotel I just keep getting this when I try to access the ActionClass through struts.xml: HTTP Status 404 - There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].type Status reportmessage There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].description The requested resource is not available. Unfortenatly the support guys at the webhotel says they lack knowledge of Tomcat so they can not help me out. If you want to change your hosting provider, there are a number of offers at http://wiki.apache.org/tomcat/PoweredBy#Hosting_providers But today I at least found this exception in the catalina.log just after my attempt yo access a struts-path: /-- Encapsulated exception \ java.lang.NullPointerException: permission can't be null at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:834) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1280) at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1481) at ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85) at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:162) at com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:77) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at ognl.ASTProperty.setValueBody(ASTProperty.java:127) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220) at ognl.SimpleNode.setValue(SimpleNode.java:301) at ognl.Ognl.setValue(Ognl.java:737) at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:217) at com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:186) at com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:173) at com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:151) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:292) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:203) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:211) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:190) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:75) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:90) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:243) at com.opensymphony.xwork2
RE: 404 - Might there be something wrong with my permissions?
Hello guys! I started my tomcat at home with catalina.bat start -security. During startup I at once got a lot of exceptions, please see this pastie:http://pastie.org/8499210 When I try to access the webapp I get 404 right away.At the production server I at least could access the jsp:s direct, but through struts I got 404.Now at home I just get 404 in both ways. One interesting thing is that it looks like the app do not got permissions to load the struts-default.xml: Caused by: Caught exception while loading file struts-default.xml ...that could be the same issue in production since no struts is working at all. I have not worked with permissions before but examing the catalina.policy with polycytool I see there is alot of settings like:java.util.PropertyPermission java.vm.version read...that I guess means that it is OK to read the System.getProperty(java.vm.version); If you draw any conclusion about my app like is there any permission I need to set to make it work (I guess it must be able to read struts-default.xml for eg), please let me know. Then I will get in contact with the webhotel-support and try to ask them to tell me if they got that permission-settings. Best regardsFredrik From: fredan...@hotmail.com To: users@tomcat.apache.org Subject: RE: 404 - Might there be something wrong with my permissions? Date: Thu, 21 Nov 2013 15:46:07 + Hello Konstantin!Thanks for your reply!Yes the message got really hard to read, it looked fine when I send it!My apologies for that!I will start to investigate your advice right away!Sounds really interesting!I will get back as soon I got any new info!Best regards and thanks alot again!/Fredrik Date: Thu, 21 Nov 2013 17:10:58 +0400 Subject: Re: 404 - Might there be something wrong with my permissions? From: knst.koli...@gmail.com To: users@tomcat.apache.org 2013/11/21 Fredrik Andersson fredan...@hotmail.com: Hello Tomcat-experts! It is hard to read you message. I have recently bought some space at a webhotel that uses Apache HTTP server as front before a Tomcat 6.0.37.My account at the webhotel is said to support Struts and Hibernate and such technics.At home I have developed a app that uses those technics and of course it runs fine in a similar environment as the one at the webhotel. I can deploy my app as a ROOT-app or a ordinary app and the Struts works perfectly. At the webhotel I have tried to deploy it booth as a ROOT-app and as a MYAPP-webapp-1.0.0.war-file Now I have stripped the app down to just a struts2-hello-world-app. But at the webhotel I just keep getting this when I try to access the ActionClass through struts.xml: HTTP Status 404 - There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].type Status reportmessage There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].description The requested resource is not available. Unfortenatly the support guys at the webhotel says they lack knowledge of Tomcat so they can not help me out. If you want to change your hosting provider, there are a number of offers at http://wiki.apache.org/tomcat/PoweredBy#Hosting_providers But today I at least found this exception in the catalina.log just after my attempt yo access a struts-path: /-- Encapsulated exception \ java.lang.NullPointerException: permission can't be null at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:834) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1280) at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1481) at ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85) at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:162) at com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:77) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at ognl.ASTProperty.setValueBody(ASTProperty.java:127) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220) at ognl.SimpleNode.setValue(SimpleNode.java:301) at ognl.Ognl.setValue(Ognl.java:737) at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:217) at com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:186) at com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:173) at com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:151) at com.opensymphony.xwork2
404 - Might there be something wrong with my permissions?
Hello Tomcat-experts! I have recently bought some space at a webhotel that uses Apache HTTP server as front before a Tomcat 6.0.37.My account at the webhotel is said to support Struts and Hibernate and such technics.At home I have developed a app that uses those technics and of course it runs fine in a similar environment as the one at the webhotel. I can deploy my app as a ROOT-app or a ordinary app and the Struts works perfectly. At the webhotel I have tried to deploy it booth as a ROOT-app and as a MYAPP-webapp-1.0.0.war-file Now I have stripped the app down to just a struts2-hello-world-app. But at the webhotel I just keep getting this when I try to access the ActionClass through struts.xml: HTTP Status 404 - There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].type Status reportmessage There is no Action mapped for namespace [/] and action name [welcome] associated with context path [/MYAPP-webapp-1.0.0].description The requested resource is not available. Unfortenatly the support guys at the webhotel says they lack knowledge of Tomcat so they can not help me out.But today I at least found this exception in the catalina.log just after my attempt yo access a struts-path: /-- Encapsulated exception \ java.lang.NullPointerException: permission can't be null at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:834) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1280) at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1481) at ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85) at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:162) at com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:77) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2318) at ognl.ASTProperty.setValueBody(ASTProperty.java:127) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220) at ognl.SimpleNode.setValue(SimpleNode.java:301) at ognl.Ognl.setValue(Ognl.java:737) at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:217) at com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:186) at com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:173) at com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:151) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:292) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:203) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:211) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:190) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:75) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:90) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:243) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:100) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:141) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249) at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:171) at
Re: Controlling permissions when creating directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott, On 7/30/13 1:51 PM, sderrick wrote: The host we use, uses the java service wrapper to launch tomcat so I added wrapper.java.umask=0002 to the .conf file. Now I can ratchet the the permissions down with PosixFilePermisions All is well now. So, Java won't override a process umask. Interesting. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR+SlnAAoJEBzwKT+lPKRYAHsQALDYRHapcaDFK0/c7XGcZV3j PPGI/p1QMYClUTDl88KYLNPeC+7URNN4AHdYrbYCFjPgBi9dyqLKGRWHN28pCelU Ly11wswdxkGUc9qjgOcYNpFCZw/KG6F8rcWz9lkdgGKbN8rn8dDP90fb2Vem06IA lY3wUsjdbKW7CF+QO27n8Mcjc4eNISfTx20hvMyyl8phfZ6UcMzjOVArpkJ7uomN 3XeXR/Z/MGoFmbg+HdoEC+8BRTuTYroaZRg6G7mGNKM1QUPxCZeZ5XNuqptUBWx3 rubq6pi3sKEj28tbJ9TOmcGMJgTpwqPIbVvWARF3dEg8tl6DhX5DbkEDG/ujjF2s ibG2o2ddeMXia1mQuKXczOaTBNHhLoNPPZvHnleAIeuj8gWZcYKKbbmNn774ddki gFppPx6qYMQwR6P80RLyM5Og3rp4tkUI8I5f5EgS1kbWBu10GUr8uefLZfxpKODS fZITIi8DEvwst1o3n7Kk8SQjY1fNhqlLMY9sKbOa6CDHNmHsOjjWtzOA937qwyG5 ounXgKnE5AlzfJaCWcFn8XtpCk83BTRYaLSb4uutM6cEaygRxDM1tKjB+fDuEiir v8G4ugMXjA7sbuCvBBTGKEmH8s9oYKi3TMazYcz3sfsAj9NpyQn9tJZdKlTUxNuy 3U3R9en2RNjm6BRMY4eR =U3r5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Controlling permissions when creating directories
Hi Scott, Try following 1. Stop the services 2. Set the umask to 002. Command for the same is umask 022 3. Start the services Remember you need to perform all above in a single shell/terminal. Above umask will give permissions are as follows Directory 775 File 664 Regards, Vidyadhar Sent on my BlackBerry® from Vodafone -Original Message- From: Christopher Schultz ch...@christopherschultz.net Date: Mon, 29 Jul 2013 21:16:57 To: Tomcat Users Listusers@tomcat.apache.org Reply-To: Tomcat Users List users@tomcat.apache.org Subject: Re: Controlling permissions when creating directories -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott, On 7/29/13 8:36 PM, Scott Derrick wrote: I am using tomcat7, on centOS6 The app crates a folder, uploads a file to the folder, processes the file and then provides a download link to the resulting file. All this works fine on a tomcat7 server running on my desktop machine. Running tomcat7 on the server, its broke. I create the folder, OK. I upload the file, OK I run the first process, NOT! I've tracked it down the permissions on the created folders. They don't have write access on the group, so the write fails. If I manually change the permission to 0760 it works fine. I specify write permissions when I create the folder but it doesn't get set. Pesky Java 7 API. I'll have to read-up on that some time. Its always drwxr-x--- My code in the servlet is */ Path imagePath = Paths.get(baseDir, user, Accession, Accession); SetPosixFilePermission perms = PosixFilePermissions.fromString(rwxrwxr--); FileAttributeSetlt;PosixFilePermission attr = PosixFilePermissions.asFileAttribute(perms); Files.createDirectory(imagePath.toAbsolutePath(), attr);/ * The permissions must be overridden somewhere. If I apply a more restrictive permission, say 0600, that gets set correctly., I can't seem to set the group permission to writable. Any ideas! I've been banging on this for hours! Any idea how PosixFilePermissions works with the process's umask? What kind of filesystem is it? What is the umask of the process? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR9xQGAAoJEBzwKT+lPKRY8UwP/RAvdvFPWwSb5W3OsOf1Veh0 hDLXTz3vV6gTDhPwiWMnuoAZEKLEz+kcJqMeeJxt1w1+pzcnm2JOnHETr95SpXuC X9LT2Qi3w686E2BrHjm+5ad1KN4KqXmcU0Eyh8HLPudyZwiNBMkhY8o3pLLDTEZF 4TxTzQoNSFSXsX1UcCQQM0bUYsURuvamhs8xytSa1VrTKLJUxaGFicZ+g+OVR5In Zg5Fg/BfjWDKGYW1ILWDaVG8dwCZ+CCwOOq6kBNZaU9zaPY2TSfkC8XAiY7xvah9 noLYUsSi2yEThqcPkn9QFZcKZFw24Vu7wQwhp2NihsKWu+WqAYOhFwRXegER6lnL k7JAuE/35+Y5V2Kxei34Ov/UW8tsuMi8c9G3B3lhBeaCT1MFMnjcpZn2LWeoXzBE 5of6TFQYmMjVhj0NJXBpThluomSkhOh9XmyWyzLcT+HmOjsAD+U30z5GrNBqFjN7 Sh4Xywrdolg8qS75mc4D6tf1vXkKYlHCM1/TOchB+8xdQPOQ+O97pDxzthKdpij7 5KuoNT/n2Zfdsuu5DVS3xjROeyst5Elwb6DNsSnAgzCjBxf8GFNniURcsoXA074t M6IXIMnen4lA/ipvRrV0iKQz+DNkiriDi8HA4Ze2ecE9LY6ETCW5ax4x518xeFty e8YrrK03AKUtpe9y5oWC =OOCi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Controlling permissions when creating directories
Vidyadhar, thanks for the tip! The host we use, uses the java service wrapper to launch tomcat so I added wrapper.java.umask=0002 to the .conf file. Now I can ratchet the the permissions down with PosixFilePermisions All is well now. thanks again, Scott Original Message Subject: Re: Controlling permissions when creating directories From: Techienote com [via Tomcat] lt;ml-node+s10n500236...@n6.nabble.comgt; To: sderrick lt;sc...@tnstaafl.netgt; Date: 07/30/2013 08:52 AM Hi Scott, Try following 1. Stop the services 2. Set the umask to 002. Command for the same is umask 022 3. Start the services Remember you need to perform all above in a single shell/terminal. Above umask will give permissions are as follows Directory 775 File 664 Regards, Vidyadhar Sent on my BlackBerry® from Vodafone -Original Message- From: Christopher Schultz lt; [hidden email] gt; Date: Mon, 29 Jul 2013 21:16:57 To: Tomcat Users Listlt; [hidden email] gt; Reply-To: Tomcat Users List lt; [hidden email] gt; Subject: Re: Controlling permissions when creating directories -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott, On 7/29/13 8:36 PM, Scott Derrick wrote: gt; I am using tomcat7, on centOS6 gt; gt; The app crates a folder, uploads a file to the folder, processes gt; the file and then provides a download link to the resulting file. gt; All this works fine on a tomcat7 server running on my desktop gt; machine. Running tomcat7 on the server, its broke. gt; gt; I create the folder, OK. I upload the file, OK I run the first gt; process, NOT! gt; gt; I've tracked it down the permissions on the created folders. They gt; don't have write access on the group, so the write fails. If I gt; manually change the permission to 0760 it works fine. I specify gt; write permissions when I create the folder but it doesn't get set. Pesky Java 7 API. I'll have to read-up on that some time. gt; Its always drwxr-x--- My code in the servlet is gt; gt; */ Path imagePath = Paths.get(baseDir, user, Accession, gt; Accession); Setlt;PosixFilePermissiongt; perms = gt; PosixFilePermissions.fromString(rwxrwxr--); gt; FileAttributelt;Setamp;lt;PosixFilePermissiongt;gt; attr = gt; PosixFilePermissions.asFileAttribute(perms); gt; Files.createDirectory(imagePath.toAbsolutePath(), attr);/ * gt; gt; The permissions must be overridden somewhere. If I apply a more gt; restrictive permission, say 0600, that gets set correctly., I can't gt; seem to set the group permission to writable. gt; gt; Any ideas! I've been banging on this for hours! Any idea how PosixFilePermissions works with the process's umask? What kind of filesystem is it? What is the umask of the process? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR9xQGAAoJEBzwKT+lPKRY8UwP/RAvdvFPWwSb5W3OsOf1Veh0 hDLXTz3vV6gTDhPwiWMnuoAZEKLEz+kcJqMeeJxt1w1+pzcnm2JOnHETr95SpXuC X9LT2Qi3w686E2BrHjm+5ad1KN4KqXmcU0Eyh8HLPudyZwiNBMkhY8o3pLLDTEZF 4TxTzQoNSFSXsX1UcCQQM0bUYsURuvamhs8xytSa1VrTKLJUxaGFicZ+g+OVR5In Zg5Fg/BfjWDKGYW1ILWDaVG8dwCZ+CCwOOq6kBNZaU9zaPY2TSfkC8XAiY7xvah9 noLYUsSi2yEThqcPkn9QFZcKZFw24Vu7wQwhp2NihsKWu+WqAYOhFwRXegER6lnL k7JAuE/35+Y5V2Kxei34Ov/UW8tsuMi8c9G3B3lhBeaCT1MFMnjcpZn2LWeoXzBE 5of6TFQYmMjVhj0NJXBpThluomSkhOh9XmyWyzLcT+HmOjsAD+U30z5GrNBqFjN7 Sh4Xywrdolg8qS75mc4D6tf1vXkKYlHCM1/TOchB+8xdQPOQ+O97pDxzthKdpij7 5KuoNT/n2Zfdsuu5DVS3xjROeyst5Elwb6DNsSnAgzCjBxf8GFNniURcsoXA074t M6IXIMnen4lA/ipvRrV0iKQz+DNkiriDi8HA4Ze2ecE9LY6ETCW5ax4x518xeFty e8YrrK03AKUtpe9y5oWC =OOCi -END PGP SIGNATURE
Controlling permissions when creating directories
I am using tomcat7, on centOS6 The app crates a folder, uploads a file to the folder, processes the file and then provides a download link to the resulting file. All this works fine on a tomcat7 server running on my desktop machine. Running tomcat7 on the server, its broke. I create the folder, OK. I upload the file, OK I run the first process, NOT! I've tracked it down the permissions on the created folders. They don't have write access on the group, so the write fails. If I manually change the permission to 0760 it works fine. I specify write permissions when I create the folder but it doesn't get set. Its always drwxr-x--- My code in the servlet is */ Path imagePath = Paths.get(baseDir, user, Accession, Accession); SetPosixFilePermission perms = PosixFilePermissions.fromString(rwxrwxr--); FileAttributeSetlt;PosixFilePermission attr = PosixFilePermissions.asFileAttribute(perms); Files.createDirectory(imagePath.toAbsolutePath(), attr);/ * The permissions must be overridden somewhere. If I apply a more restrictive permission, say 0600, that gets set correctly., I can't seem to set the group permission to writable. Any ideas! I've been banging on this for hours! thanks, Scott -- I don't believe in a government that protects us from ourselves. Ronald Reagan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Controlling permissions when creating directories
I am using tomcat7, on centOS6 The app crates a folder, uploads a file to the folder, processes the file and then provides a download link to the resulting file. All this works fine on a tomcat7 server running on my desktop machine. Running tomcat7 on the server, its broke. I create the folder, OK. I upload the file, OK I run the first process, NOT! I've tracked it down the permissions on the created folders. They don't have write access on the group, so the write fails. If I manually change the permission to 0760 it works fine. I specify write permissions when I create the folder but it doesn't get set. Its always drwxr-x--- My code in the servlet is */Path imagePath = Paths.get(baseDir, user, Accession, Accession); SetPosixFilePermission perms = PosixFilePermissions.fromString(rwxrwxr--); FileAttributeSetamp;lt;PosixFilePermission attr = PosixFilePermissions.asFileAttribute(perms); Files.createDirectory(imagePath.toAbsolutePath(), attr);/ * The permissions must be overridden somewhere. If I apply a more restrictive permission, say 0600, that gets set correctly., I can't seem to set the group permission to writable. Any ideas! I've been banging on this for hours! thanks, Scott -- View this message in context: http://tomcat.10.x6.nabble.com/Controlling-permissions-when-creating-directories-tp5002328.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Controlling permissions when creating directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott, On 7/29/13 8:36 PM, Scott Derrick wrote: I am using tomcat7, on centOS6 The app crates a folder, uploads a file to the folder, processes the file and then provides a download link to the resulting file. All this works fine on a tomcat7 server running on my desktop machine. Running tomcat7 on the server, its broke. I create the folder, OK. I upload the file, OK I run the first process, NOT! I've tracked it down the permissions on the created folders. They don't have write access on the group, so the write fails. If I manually change the permission to 0760 it works fine. I specify write permissions when I create the folder but it doesn't get set. Pesky Java 7 API. I'll have to read-up on that some time. Its always drwxr-x--- My code in the servlet is */ Path imagePath = Paths.get(baseDir, user, Accession, Accession); SetPosixFilePermission perms = PosixFilePermissions.fromString(rwxrwxr--); FileAttributeSetlt;PosixFilePermission attr = PosixFilePermissions.asFileAttribute(perms); Files.createDirectory(imagePath.toAbsolutePath(), attr);/ * The permissions must be overridden somewhere. If I apply a more restrictive permission, say 0600, that gets set correctly., I can't seem to set the group permission to writable. Any ideas! I've been banging on this for hours! Any idea how PosixFilePermissions works with the process's umask? What kind of filesystem is it? What is the umask of the process? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR9xQGAAoJEBzwKT+lPKRY8UwP/RAvdvFPWwSb5W3OsOf1Veh0 hDLXTz3vV6gTDhPwiWMnuoAZEKLEz+kcJqMeeJxt1w1+pzcnm2JOnHETr95SpXuC X9LT2Qi3w686E2BrHjm+5ad1KN4KqXmcU0Eyh8HLPudyZwiNBMkhY8o3pLLDTEZF 4TxTzQoNSFSXsX1UcCQQM0bUYsURuvamhs8xytSa1VrTKLJUxaGFicZ+g+OVR5In Zg5Fg/BfjWDKGYW1ILWDaVG8dwCZ+CCwOOq6kBNZaU9zaPY2TSfkC8XAiY7xvah9 noLYUsSi2yEThqcPkn9QFZcKZFw24Vu7wQwhp2NihsKWu+WqAYOhFwRXegER6lnL k7JAuE/35+Y5V2Kxei34Ov/UW8tsuMi8c9G3B3lhBeaCT1MFMnjcpZn2LWeoXzBE 5of6TFQYmMjVhj0NJXBpThluomSkhOh9XmyWyzLcT+HmOjsAD+U30z5GrNBqFjN7 Sh4Xywrdolg8qS75mc4D6tf1vXkKYlHCM1/TOchB+8xdQPOQ+O97pDxzthKdpij7 5KuoNT/n2Zfdsuu5DVS3xjROeyst5Elwb6DNsSnAgzCjBxf8GFNniURcsoXA074t M6IXIMnen4lA/ipvRrV0iKQz+DNkiriDi8HA4Ze2ecE9LY6ETCW5ax4x518xeFty e8YrrK03AKUtpe9y5oWC =OOCi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat running with a shared unix group but unable to read files with group permissions
On Thu, Sep 06, 2012 at 10:50:30AM -0700, Udam Dewaraja wrote:
Hi all,
I'm stumped on a seemingly java/tomcat related issue and am hoping someone
can provide some help.
We have two users ('user1' and 'user2') on our linux server that share the
same group ('group1'). User 'user1' writes some files that have the
following permissions:
-rw-r- 1 user1 group1 788 Sep 5 19:42 file.log
The folder containing this file has the following permissions:
drwxr-xr-- 2 user1 group1 4096 Sep 5 19:42 log
The tomcat web app is launched as user 'user2'. Below is the ps output for
the process. I've also verified that the java web app is running with gid
of the shared group 'group1'.
user231920 31919 99 21:30 ?00:00:36 /usr/local/jre/bin/java
org.apache.catalina.startup.Bootstrap start
When the web app tries to read the file, *it gets the following exception*:
java.io.FileNotFoundException: /foo/bar/data/log/file.log (Permission
denied)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:233)
at java.io.RandomAccessFile.init(RandomAccessFile.java:118)
…
at java.lang.Thread.run(Thread.java:679)
However, while logged in as 'user2', I can run a simple
cat /foo/bar/data/log/file.log and* I can read the contents of the file*.
Also, if I provide 'other' read permissions to the file (e.g. -rw-r--r--
1 user1 group1 788 Sep 5 19:42 file.log), *the web app is able to read
the file*.
If I write a sample java application that tries to read this file and
execute it while logged in as 'user2', again *Java is able to read the file.
*
Tomcat doesn't seem to be using any security policy as far as I can tell.
Any ideas why the group permissions seem to be ignored by tomcat?
Please try to check ulimit (pam) settings in your OS.
--
Peter Benko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat running with a shared unix group but unable to read files with group permissions
Hi all,
I'm stumped on a seemingly java/tomcat related issue and am hoping someone
can provide some help.
We have two users ('user1' and 'user2') on our linux server that share the
same group ('group1'). User 'user1' writes some files that have the
following permissions:
-rw-r- 1 user1 group1 788 Sep 5 19:42 file.log
The folder containing this file has the following permissions:
drwxr-xr-- 2 user1 group1 4096 Sep 5 19:42 log
The tomcat web app is launched as user 'user2'. Below is the ps output for
the process. I've also verified that the java web app is running with gid
of the shared group 'group1'.
user231920 31919 99 21:30 ?00:00:36 /usr/local/jre/bin/java
org.apache.catalina.startup.Bootstrap start
When the web app tries to read the file, *it gets the following exception*:
java.io.FileNotFoundException: /foo/bar/data/log/file.log (Permission
denied)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:233)
at java.io.RandomAccessFile.init(RandomAccessFile.java:118)
…
at java.lang.Thread.run(Thread.java:679)
However, while logged in as 'user2', I can run a simple
cat /foo/bar/data/log/file.log and* I can read the contents of the file*.
Also, if I provide 'other' read permissions to the file (e.g. -rw-r--r--
1 user1 group1 788 Sep 5 19:42 file.log), *the web app is able to read
the file*.
If I write a sample java application that tries to read this file and
execute it while logged in as 'user2', again *Java is able to read the file.
*
Tomcat doesn't seem to be using any security policy as far as I can tell.
Any ideas why the group permissions seem to be ignored by tomcat?
Thanks!
Udam
Re: Tomcat running with a shared unix group but unable to read files with group permissions
Udam Dewaraja wrote:
Hi all,
I'm stumped on a seemingly java/tomcat related issue and am hoping someone
can provide some help.
We have two users ('user1' and 'user2') on our linux server that share the
same group ('group1'). User 'user1' writes some files that have the
following permissions:
-rw-r- 1 user1 group1 788 Sep 5 19:42 file.log
The folder containing this file has the following permissions:
drwxr-xr-- 2 user1 group1 4096 Sep 5 19:42 log
The tomcat web app is launched as user 'user2'. Below is the ps output for
the process. I've also verified that the java web app is running with gid
of the shared group 'group1'.
user231920 31919 99 21:30 ?00:00:36 /usr/local/jre/bin/java
org.apache.catalina.startup.Bootstrap start
When the web app tries to read the file, *it gets the following exception*:
java.io.FileNotFoundException: /foo/bar/data/log/file.log (Permission
denied)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:233)
at java.io.RandomAccessFile.init(RandomAccessFile.java:118)
…
at java.lang.Thread.run(Thread.java:679)
However, while logged in as 'user2', I can run a simple
cat /foo/bar/data/log/file.log and* I can read the contents of the file*.
Also, if I provide 'other' read permissions to the file (e.g. -rw-r--r--
1 user1 group1 788 Sep 5 19:42 file.log), *the web app is able to read
the file*.
If I write a sample java application that tries to read this file and
execute it while logged in as 'user2', again *Java is able to read the file.
*
Tomcat doesn't seem to be using any security policy as far as I can tell.
Any ideas why the group permissions seem to be ignored by tomcat?
Nothing to do with Tomcat I think.
Maybe it is because java.io.RandomAccessFile is a read/write kind of file, and the group
just has read permission ?
All your tests involve reading, not writing, and reading is allowed for the
group.
Google for java.io.RandomAccessFile.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat running with a shared unix group but unable to read files with group permissions
In my code, the RandomAccess file is trying to do a read (code below).
That's why all my tests are doing reads.
logFile = new RandomAccessFile(fileToRead, r);
The sample java application I ran executes the exact same line above (with
the same file) and reads the contents correctly. However, in Tomcat webapp,
this fails.
Thanks,
Udam
On Thu, Sep 6, 2012 at 1:15 PM, André Warnier a...@ice-sa.com wrote:
Udam Dewaraja wrote:
Hi all,
I'm stumped on a seemingly java/tomcat related issue and am hoping someone
can provide some help.
We have two users ('user1' and 'user2') on our linux server that share the
same group ('group1'). User 'user1' writes some files that have the
following permissions:
-rw-r- 1 user1 group1 788 Sep 5 19:42 file.log
The folder containing this file has the following permissions:
drwxr-xr-- 2 user1 group1 4096 Sep 5 19:42 log
The tomcat web app is launched as user 'user2'. Below is the ps output for
the process. I've also verified that the java web app is running with gid
of the shared group 'group1'.
user231920 31919 99 21:30 ?00:00:36 /usr/local/jre/bin/java
org.apache.catalina.startup.**Bootstrap start
When the web app tries to read the file, *it gets the following
exception*:
java.io.FileNotFoundException: /foo/bar/data/log/file.log (Permission
denied)
at java.io.RandomAccessFile.open(**Native Method)
at java.io.RandomAccessFile.**init(RandomAccessFile.java:**233)
at java.io.RandomAccessFile.**init(RandomAccessFile.java:**118)
…
at java.lang.Thread.run(Thread.**java:679)
However, while logged in as 'user2', I can run a simple
cat /foo/bar/data/log/file.log and* I can read the contents of the file*.
Also, if I provide 'other' read permissions to the file (e.g. -rw-r--r--
1 user1 group1 788 Sep 5 19:42 file.log), *the web app is able to read
the file*.
If I write a sample java application that tries to read this file and
execute it while logged in as 'user2', again *Java is able to read the
file.
*
Tomcat doesn't seem to be using any security policy as far as I can tell.
Any ideas why the group permissions seem to be ignored by tomcat?
Nothing to do with Tomcat I think.
Maybe it is because java.io.RandomAccessFile is a read/write kind of file,
and the group just has read permission ?
All your tests involve reading, not writing, and reading is allowed for
the group.
Google for java.io.RandomAccessFile.
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 JDK 7 access permissions: error or bug?
2012/1/17 deniz denizdurmu...@gmail.com:
Hi all,
I am getting a weird error on tomcat 7. at first i deploy my war file and
everything is smooth.. but after some time - randomly - i cant access
anything on tomcat and in the log file I see these lines:
code
Jan 17, 2012 11:37:37 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
java.security.AccessControlException: access denied
(java.net.SocketPermission 127.0.0.1:50092 accept,resolve)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
at
java.security.AccessController.checkPermission(AccessController.java:555)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkAccept(SecurityManager.java:1174)
at java.net.ServerSocket.implAccept(ServerSocket.java:526)
at java.net.ServerSocket.accept(ServerSocket.java:490)
at
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
at
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:207)
at java.lang.Thread.run(Thread.java:722)
/code
i have to kill tomcat and then after some time it happens again... any
ideas?
The catalina.policy file that comes with Tomcat grants AllPermission
to both Tomcat and JRE libs (${catalina.home}/lib/-,
${java.home}/lib/-).
The stacktrace that you show above, as well as ones in [1] all show
only Tomcat or JRE classes, so all permissions must be granted,
unless there is something that I miss.
What is puzzling is that you say that the failure starts to occur randomly.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52482
You have to be more specific about your configuration (OS, JRE
version, Tomcat settings (server.xml without comments)) and try to
provide a scenario to reproduce the issue on a clean installation of
Tomcat.
While the issue cannot be reproduced and if nobody here on users@ is
able to reproduce it or find some clues, filing an issue in bugzilla
is useless, as we cannot proceed from there if the issue is not
understood. It might as well be some configuration error or
programming error in the web application.
You may want to
1. Reconfigure your logging to use the following formatter:
org.apache.juli.OneLineFormatter
E.g.:
1catalina.org.apache.juli.FileHandler.formatter =
org.apache.juli.OneLineFormatter
It prints current thread name with each log message.
2. Reconfigure your access log to include thread name in the access log (%I)
Maybe you can find what requests were handled by those threads before
the failure starts to occurs.
Thus far I do not observe any issues with Tomcat 7.0.25, JDK 1.7.0.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 JDK 7 access permissions: error or bug?
Well thank you for your kind responses... i have found out the problem today... i have been focused on a wrong place... although logs were showing clear exceptions and errors, the problem was in java classes of my webapp not jsps nor tomcat itself... -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat-7-JDK-7-access-permissions-error-or-bug-tp3679835p3874666.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 JDK 7 access permissions: error or bug?
On 17/01/2012 03:44, deniz wrote: Hi all, I am getting a weird error on tomcat 7. at first i deploy my war file and everything is smooth.. but after some time - randomly - i cant access anything on tomcat and in the log file I see these lines: Exactly which version, Tomcat 7.0.? p code Jan 17, 2012 11:37:37 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:50092 accept,resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1174) at java.net.ServerSocket.implAccept(ServerSocket.java:526) at java.net.ServerSocket.accept(ServerSocket.java:490) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:207) at java.lang.Thread.run(Thread.java:722) /code i have to kill tomcat and then after some time it happens again... any ideas? -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat-7-JDK-7-access-permissions-error-or-bug-tp3679835p3679835.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat 7 JDK 7 access permissions: error or bug?
7.0.23 is this a bug in this version? -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat-7-JDK-7-access-permissions-error-or-bug-tp3679835p3680278.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 JDK 7 access permissions: error or bug?
Exactly which version, Tomcat 7.0.? 7.0.23 On 17/01/2012 03:44, deniz wrote: Hi all, I am getting a weird error on tomcat 7. at first i deploy my war file and everything is smooth.. but after some time - randomly - i cant access anything on tomcat and in the log file I see these lines: Exactly which version, Tomcat 7.0.? p code Jan 17, 2012 11:37:37 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:50092 accept,resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1174) at java.net.ServerSocket.implAccept(ServerSocket.java:526) at java.net.ServerSocket.accept(ServerSocket.java:490) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:207) at java.lang.Thread.run(Thread.java:722) /code i have to kill tomcat and then after some time it happens again... any ideas? -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat-7-JDK-7-access-permissions-error-or-bug-tp3679835p3679835.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 JDK 7 access permissions: error or bug?
Hi all, I am getting a weird error on tomcat 7. at first i deploy my war file and everything is smooth.. but after some time - randomly - i cant access anything on tomcat and in the log file I see these lines: code Jan 17, 2012 11:37:37 AM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:50092 accept,resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkAccept(SecurityManager.java:1174) at java.net.ServerSocket.implAccept(ServerSocket.java:526) at java.net.ServerSocket.accept(ServerSocket.java:490) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:207) at java.lang.Thread.run(Thread.java:722) /code i have to kill tomcat and then after some time it happens again... any ideas? -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat-7-JDK-7-access-permissions-error-or-bug-tp3679835p3679835.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat file permissions
We're launching Tomcat 7 under Linux using jsvc, and having it run under the tomcat7 user we created. The issue we're seeing is that we had a webapp that was misconfigured, so that the tomcat7 user and all groups it is under did not have read access to the files. These files do not have world read set. However, the webapp is working just fine and must be reading those files. It is acting as though it is running as root, but I can clearly see the second jsvc process running as tomcat7. Does anyone know why it appears to be having root read on the filesystem? Or is this a Commons Daemon question? Thanks, Richard - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat file permissions
2011/8/2 Richard Frovarp rfrov...@apache.org: We're launching Tomcat 7 under Linux using jsvc, and having it run under the tomcat7 user we created. For record, what exact versions of each, especially of jsvc? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat file permissions
On 08/02/2011 03:37 PM, Konstantin Kolinko wrote: 2011/8/2 Richard Frovarprfrov...@apache.org: We're launching Tomcat 7 under Linux using jsvc, and having it run under the tomcat7 user we created. For record, what exact versions of each, especially of jsvc? Tomcat 7.0.16 JSVC 1.0.5 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2010-3718 Apache Tomcat Local bypass of security manger file permissions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CVE-2010-3718 Apache Tomcat Local bypass of security manger file permissions
Severity: Low
Vendor: The Apache Software Foundation
Versions Affected:
- - Tomcat 7.0.0 to 7.0.3
- - Tomcat 6.0.0 to 6.0.?
- - Tomcat 5.5.0 to 5.5.?
- - Earlier, unsupported versions may also be affected
Description:
When running under a SecurityManager, access to the file system is
limited but web applications are granted read/write permissions to the
work directory. This directory is used for a variety of temporary files
such as the intermediate files generated when compiling JSPs to Servlets.
The location of the work directory is specified by a ServletContect
attribute that is meant to be read-only to web applications. However,
due to a coding error, the read-only setting was not applied. Therefore
a malicious web application may modify the attribute before Tomcat
applies the file permissions. This can be used to grant read/write
permissions to any area on the file system which a malicious web
application may then take advantage of.
This vulnerability is only applicable when hosting web applications from
untrusted sources such as shared hosting environments.
Example (AL2 licensed):
Listener source
- ---
package listeners;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public final class FooListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
ServletContext context = event.getServletContext();
java.io.File workdir = (java.io.File) context
.getAttribute(javax.servlet.context.tempdir);
if (workdir.toString().indexOf(..) 0) {
context.setAttribute(javax.servlet.context.tempdir,
new java.io.File(workdir, ../../../../conf));
}
}
public void contextDestroyed(ServletContextEvent event) {
}
}
web.xml snippet
- ---
listener
listener-classlisteners.FooListener/listener-class
/listener
Mitigation:
Users of affected versions should apply one of the following mitigations:
- - Upgrade to a Tomcat version where this issue is fixed
- - Undeploy all web applications from untrusted sources
Credit:
The issue was identified by the Tomcat security team.
References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNTLBXAAoJEBDAHFovYFnnkQkQAIpE68EHXYnu70xHFThPVGPk
48OIvAA2fMzF8RajaGQRkOS3WXrzPdbjf8AXjUmZ/E3Yr+4XdP2kmDMGsW9hs/Vw
x2fXYfyBQQQMdKVnSVr3cMSPs+RhnSpPI1wsQUWnp0xZNez/9VkSDeINq8JFGXLB
5NgkQZ4+6UBBl2K/mtkVxZHnXi1y9ulvhaQ95jCTt7mzOUJrlq8NXWaEW1njtGAO
7Z6KBMn6PQkzx1k38TG6kPBN331fWWE2WhSimMkX1Q8jfI5f0PVPaQELPKieSf7x
G0zCfQ8aH0q4Kn0jsvvmP43mzCz3PbBwOpFZgPO0vcA5usXwFXGTJCKAhhCTy0CG
q9Sjxb8hLyEwg0vIrvzzlPj6g8mm6syW7Db4R4F3vW/ovCWgVdRFMhl0e/KX3nfG
MWSYq/x4wFj470/j5Ak7wz2y/GAiX9LiEwhFlEWL/SOevY9/u3l9dXIUbcYUG3mS
4dBpthU5eJc2vbdp+gtAPoJexxS9nZhCfbcNjV5HbdRHhn1dIaJhR3KYnqQU2wX2
CG2srHqTJ+3aW969nhHxgpiLmElmDlWHMNQmDDDaY9CDC2i3ZNdw4uBes4nRc7Xg
/1LQvx7pSnAidrQa6CcOjsf4usBQ6faO0zeuri9l6jwFDfwHiL/TuNzNxgmbR8BC
DgZJ/zI6FepuWKA4CV7t
=uz7D
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with security permissions and access denied page for ldap users
Any suggestions about my problem? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problem with security permissions and access denied page for ldap users
Hi,
i installed bedework calendar server and i'm trying to get bedework to
authenticate using LDAP. I added ldap jar files to the lib folder and
added this realm to server.xml file
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionName=cn=Manager,dc=mydomain,dc=com
connectionPassword=mypass
connectionURL=ldap://localhost:389;
userPattern=uid={0},ou=Users,dc=mydomain,dc=com
roleBase=ou=Groups,dc=mypass,dc=com
roleName=cn
roleSearch=(uniqueUid={0})
/
The problem is that when i access web page and enter user and password,
i get access denied page. I suppose that the reaspm is that users from
ldap has no access to these pages. What do i need to do to to give
access to these users, how to solve this problem?
I think that i configured bedework right and allowed ldap there, the
only problem that i get right now is this tomcat security issue.
I read a lot of posts related with tomcat security and this problem, but
i still cannot solve it.
Please help to solve this problem.
If you need more info, please tell me, then i will post it here.
Thanks in advanced!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WARNING: User database is not persistable - no write permissions on directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dimas, Dimas wrote: I've installed an Ubuntu Server 8.10 with the Tomcat6 package. When I start it this msg appears on the Catalina log: WARNING: User database is not persistable - no write permissions on directory Do you know why? My guess is that you don't have write permissions on the directory where the user database exists(!). Tomcat is running as what user? The user database is owned by what user? The directory where that user database resides is owned by what user? Note that unless you are using the manager application to modify users, this warning is not relevant to you. Anyway the Tomcat starts OK, but when I deploy an application (JasperServer 3.0) it doesn't start with more permissions errors on the log: Catalina log Nov 7, 2008 2:48:10 PM org.apache.catalina.core.NamingContextListener addResource WARNING: Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory] Now /that's/ a bigger problem: your Tomcat install is broken. Tomcat ships with DBCP and should always be found. Have you been playing with any of the JAR files that come with Tomcat? Have you added anything to Tomcat's library directories? Have you deployed DBCP along with your own application? If not, you should talk to the Ubuntu folks about their broken Tomcat6 package, because this doesn't happen when you install from Tomcat's official distribution. SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener java.security.AccessControlException: access denied (java.util.PropertyPermission jasperserver.root read) You also don't have proper permissions to your log directory. I tried to chown all tomcat6 directory to the tomcat6 user, and make a 777 pemission folder, but no result :( I'm guessing that this is not standard procedure when using a packaged version of Tomcat. I recommend asking for help on the Ubuntu Tomcat forums. Please note that I'm not simply trying to get you to go away: this is an Ubuntu problem and we have been told in the past that we should refer these kinds of problems to /their/ forums instead of stamping our feet and telling their users to discard their packages (which is typically what we do, because it nearly /always/ works). So, help the Ubuntu folks make things better and they'll also be better equipped to give you more information about a standard Ubuntu Tomcat install. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkUYcIACgkQ9CaO5/Lv0PC58ACfZoSnJchvJa7D3Ru0HdlWMoYO NF4AnA1FO9sfQKhuV5I0ng5p8vsNF9gb =j6Xd -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WARNING: User database is not persistable - no write permissions on directory
Hi, I've installed an Ubuntu Server 8.10 with the Tomcat6 package. When I start it this msg appears on the Catalina log: WARNING: User database is not persistable - no write permissions on directory Do you know why? Anyway the Tomcat starts OK, but when I deploy an application (JasperServer 3.0) it doesn't start with more permissions errors on the log: Catalina log Nov 7, 2008 2:48:10 PM org.apache.catalina.core.NamingContextListener addResource WARNING: Failed to register in JMX: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory] ... Nov 7, 2008 2:48:13 PM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Nov 7, 2008 2:48:13 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/jasperserver] startup failed due to previous errors Localhost log SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener java.security.AccessControlException: access denied (java.util.PropertyPermission jasperserver.root read) ... SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener org.springframework.beans.factory.BeanDefinitionStoreException: Error registering bean with name 'fileVirtualizerFactory' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Could not resolve placeholder 'java.io.tmpdir' ... SEVERE: Exception sending context initialized event to listener instance of class com.tonbeller.tbutils.res.ResourcesFactoryContextListener java.lang.ExceptionInInitializerError ... Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission tbeller.InitialResourceProvider read) ... SEVERE: Exception sending context initialized event to listener instance of class com.jaspersoft.jasperserver.war.util.SecurityContextHolderStrategyInitializer java.lang.ExceptionInInitializerError ... SEVERE: Exception sending context destroyed event to listener instance of class org.springframework.web.util.Log4jConfigListener java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write) I tried to chown all tomcat6 directory to the tomcat6 user, and make a 777 pemission folder, but no result :( Any suggestion? Thx! -- Dimas Streich i Colomeda dimas.sc http://dimas.sc ARROVA gmail.com http://gmail.com http://www.dimas.cat
Re: Permissions for Sun JSF RI and Security Manager under Tomcat 6.0?
Hi, I think I have found the cause! My application code contains the following:- FacesContext fc = FacesContext.getCurrentInstance(); ExpressionFactory ef = fc.getApplication().getExpressionFactory(); ELContext elc = fc.getELContext(); ValueExpression ve = ef.createValueExpression(elc, expr, clazz); Object result = ve.getValue(elc); The implementation of javax.el.ValueExpression is org.apache.jasper.el. JspValueExpression which is in the org.apache.jasper.el package. Access to this package is prevented by default by the catalina.properties file! Hurrah, problem resolved! However I still need somebody official to confirm this - as my hosting company wants some official statement. I will cross-post to the developer mailing list (so sorry to those affected) in case this is more of a development issue. Can anybody confirm and provide an official statement about the programmatic use of EL and security settings? Thanks, Mike On 24/06/2008, Michael Anstis [EMAIL PROTECTED] wrote: Hi, Firstly, sorry for the long stack traces in here but I included the lot incase what I discount somebody else picks up on. Anyway, when trying to use JSF 1.2-b20-FCS on Tomcat 6.0 with Java 2 Security Manager enabled I receive the below. This can be replicated by creating a new WAR and simply adding jsf-api.jar and jsf-impl.jar to the WEB-INF\lib folder on a vanila install of Tomcat 6.0. SEVERE: Exception sending context initialized event to listener instance of *class* com.sun.faces.config.GlassFishConfigureListener java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.el) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:200) at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:1874) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:546) at com.sun.faces.config.GlassFishConfigureListener.contextInitialized(GlassFishConfigureListener.java:47) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:123) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:769) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1220) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1458) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:820) at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:348) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Permissions for Sun JSF RI and Security Manager under Tomcat 6.0?
Hi, Firstly, sorry for the long stack traces in here but I included the lot incase what I discount somebody else picks up on. Anyway, when trying to use JSF 1.2-b20-FCS on Tomcat 6.0 with Java 2 Security Manager enabled I receive the below. This can be replicated by creating a new WAR and simply adding jsf-api.jar and jsf-impl.jar to the WEB-INF\lib folder on a vanila install of Tomcat 6.0. SEVERE: Exception sending context initialized event to listener instance of *class* com.sun.faces.config.GlassFishConfigureListener java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.el) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:200) at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:1874) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:546) at com.sun.faces.config.GlassFishConfigureListener.contextInitialized(GlassFishConfigureListener.java:47) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:123) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:769) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1220) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1458) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:820) at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:348) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at
Permissions of File Created by Tomcat
Hi, I'm running a WebService using Tomcat 5.5 on Ubuntu 7.10 with Axis2. Files (and directories) are created by this service on a local directory: /myfiles/ The permission of the new directories and files in this directory are: Directories:'drwxr-xr-x 2 tomcat55 nogroup 4096' Files: '-rw-r--r-- 1 tomcat55 nogroup 10041' The problem is, is I want to access (write) these files using, say, a java application, it give me: java.io.FileNotFoundException: /myfiles/aDir/aFile.txt (Permission denied) How can I either: 1.Gain write access to these files (without having to constantly change the permissions in the command prompt, and without running my java application with 'root' access). 2.Create the files/dirs from tomcat with 'write access' 3.Other Thanking you in advance. Daniel -- View this message in context: http://www.nabble.com/Permissions-of-File-Created-by-Tomcat-tp16792720p16792720.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Permissions of File Created by Tomcat
This is really a linux permissions issue. How are you starting tomcat? with the $TOMCAT_HOME/bin/startup.sh or with jsvc or are you using an ubuntu startup script? You don't say anything about the user who will run the java application. Generally, the way to control the access permissions with which files are created in linux is to call 'umask' with the correct parameters. As mentioned before on this list umask is a shell command, so you must do it at the correct point or severely weaken the overall security of your installation. You need to do the following: 1. decide which user or users will be executing tomcat and the java application. 2. If you decide that you need to have two separate users, then make them both in the same group. 3. Use umask in the tomcat startup script and/or the shell in which you run your application to set appropriate access permissions - GIYF As an aside, if you are going to have two different processes writing these shared files you may also have to consider locking issues - maybe you have already done this. Regards Alan Chaney Daniel J Hulme wrote: Hi, I'm running a WebService using Tomcat 5.5 on Ubuntu 7.10 with Axis2. Files (and directories) are created by this service on a local directory: /myfiles/ The permission of the new directories and files in this directory are: Directories:'drwxr-xr-x 2 tomcat55 nogroup 4096' Files: '-rw-r--r-- 1 tomcat55 nogroup 10041' The problem is, is I want to access (write) these files using, say, a java application, it give me: java.io.FileNotFoundException: /myfiles/aDir/aFile.txt (Permission denied) How can I either: 1.Gain write access to these files (without having to constantly change the permissions in the command prompt, and without running my java application with 'root' access). 2.Create the files/dirs from tomcat with 'write access' 3.Other Thanking you in advance. Daniel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Permissions of File Created by Tomcat
Alan, this is very useful, thank you. After a bit of Googling I decided to upgrade to Tomcat6 (apparently is has less security ussies with Ubuntu). This means that the files/dirs are now created (from the tomcat app) by 'root:root' (with the same permissions described in my first post). However, I still have the same problem. I'm running a java progam (not as 'root'), and need write access to these files. And I'm not allowed to run my java app as 'root'. I'm pretty new to linux, so your help (i.e. command examples) is much appreciated. Daniel Alan Chaney wrote: This is really a linux permissions issue. How are you starting tomcat? with the $TOMCAT_HOME/bin/startup.sh or with jsvc or are you using an ubuntu startup script? You don't say anything about the user who will run the java application. Generally, the way to control the access permissions with which files are created in linux is to call 'umask' with the correct parameters. As mentioned before on this list umask is a shell command, so you must do it at the correct point or severely weaken the overall security of your installation. You need to do the following: 1. decide which user or users will be executing tomcat and the java application. 2. If you decide that you need to have two separate users, then make them both in the same group. 3. Use umask in the tomcat startup script and/or the shell in which you run your application to set appropriate access permissions - GIYF As an aside, if you are going to have two different processes writing these shared files you may also have to consider locking issues - maybe you have already done this. Regards Alan Chaney Daniel J Hulme wrote: Hi, I'm running a WebService using Tomcat 5.5 on Ubuntu 7.10 with Axis2. Files (and directories) are created by this service on a local directory: /myfiles/ The permission of the new directories and files in this directory are: Directories: 'drwxr-xr-x 2 tomcat55 nogroup 4096' Files: '-rw-r--r-- 1 tomcat55 nogroup 10041' The problem is, is I want to access (write) these files using, say, a java application, it give me: java.io.FileNotFoundException: /myfiles/aDir/aFile.txt (Permission denied) How can I either: 1.Gain write access to these files (without having to constantly change the permissions in the command prompt, and without running my java application with 'root' access). 2.Create the files/dirs from tomcat with 'write access' 3.Other Thanking you in advance. Daniel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Permissions-of-File-Created-by-Tomcat-tp16792720p16795633.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Permissions of File Created by Tomcat
Hi Daniel Really the issues are to do with the JVM and linux rather more than tomcat directly. I can't claim to be a linux guru but you should look at it in the following way Any application which runs on linux is 'owned' by a user. There two classifications - 'system' users and 'normal' users. System users have UIDs which are less than 1024 and can invoke privileged services. 'root' is a system (privileged) user. One issue which often seems to confuse people is that the JVM is a program not an operating system. When you 'run tomcat' you are actually invoking java on the tomcat bootstrap.jar. See the javadocs http://tomcat.apache.org/tomcat-6.0-doc/api/index.html for more details. My point here is that java is 'just another program' to linux, and all the permissions rules apply to the user invoking an application. You say that tomcat is now running as root (which is a BAD THING) which implies that you are: a. logging in as root and starting tomcat OR b. letting tomcat be started by a sys init process. One decision you must make is whether or not tomcat should be allowed to access privileged ports (eg port 80) If so, then you should start tomcat using something like jsvc (see http://commons.apache.org/daemon/index.html) which when properly configured will allow you to start an app as root, bind tomcat to port 80 and then switch to a 'tomcat' user. You can set umask permissions as appropriate in the startup script. If you intend to run tomcat with its default port of 8080 (or any non-privileged port) things are a bit simpler. Create a user on your system (maybe 'mytomcat') and then simply start the tomcat ./bin/startup.sh as this user by something like: su mytomcat -c $JAVA_HOME/bin/startup.sh from within the init script. You can, of course, su to the user you are running the other java program as, then tomcat and your app will have the same user privileges - or you can create a tomcat group, make this the main group for your tomcat user, add it as another group to your 'application' user and set the appropriate umask (002) to allow group read/write (you must also set the directory permissions accordingly - set the 's' bit) Please note that these are only pointers not a rigorous set of instructions. The reality is that if you want to do anything serious in linux you must learn ins and outs of 'bash' and this list is not really the place to do that. HTH Alan Daniel J Hulme wrote: Alan, this is very useful, thank you. After a bit of Googling I decided to upgrade to Tomcat6 (apparently is has less security ussies with Ubuntu). This means that the files/dirs are now created (from the tomcat app) by 'root:root' (with the same permissions described in my first post). However, I still have the same problem. I'm running a java progam (not as 'root'), and need write access to these files. And I'm not allowed to run my java app as 'root'. I'm pretty new to linux, so your help (i.e. command examples) is much appreciated. Daniel Alan Chaney wrote: This is really a linux permissions issue. How are you starting tomcat? with the $TOMCAT_HOME/bin/startup.sh or with jsvc or are you using an ubuntu startup script? You don't say anything about the user who will run the java application. Generally, the way to control the access permissions with which files are created in linux is to call 'umask' with the correct parameters. As mentioned before on this list umask is a shell command, so you must do it at the correct point or severely weaken the overall security of your installation. You need to do the following: 1. decide which user or users will be executing tomcat and the java application. 2. If you decide that you need to have two separate users, then make them both in the same group. 3. Use umask in the tomcat startup script and/or the shell in which you run your application to set appropriate access permissions - GIYF As an aside, if you are going to have two different processes writing these shared files you may also have to consider locking issues - maybe you have already done this. Regards Alan Chaney Daniel J Hulme wrote: Hi, I'm running a WebService using Tomcat 5.5 on Ubuntu 7.10 with Axis2. Files (and directories) are created by this service on a local directory: /myfiles/ The permission of the new directories and files in this directory are: Directories:'drwxr-xr-x 2 tomcat55 nogroup 4096' Files: '-rw-r--r-- 1 tomcat55 nogroup 10041' The problem is, is I want to access (write) these files using, say, a java application, it give me: java.io.FileNotFoundException: /myfiles/aDir/aFile.txt (Permission denied) How can I either: 1.Gain write access to these files (without having to constantly change the permissions in the command prompt, and without running my java application with 'root' access). 2.Create the files/dirs from tomcat with 'write access' 3.Other Thanking you in advance
Re: Permissions of File Created by Tomcat
SORTED! Thanks Alan. In the end I created a new user, and I'm running tomcat and my java app with this new user. Thanks again, you've been a great help. Daniel Alan Chaney wrote: Hi Daniel Really the issues are to do with the JVM and linux rather more than tomcat directly. I can't claim to be a linux guru but you should look at it in the following way Any application which runs on linux is 'owned' by a user. There two classifications - 'system' users and 'normal' users. System users have UIDs which are less than 1024 and can invoke privileged services. 'root' is a system (privileged) user. One issue which often seems to confuse people is that the JVM is a program not an operating system. When you 'run tomcat' you are actually invoking java on the tomcat bootstrap.jar. See the javadocs http://tomcat.apache.org/tomcat-6.0-doc/api/index.html for more details. My point here is that java is 'just another program' to linux, and all the permissions rules apply to the user invoking an application. You say that tomcat is now running as root (which is a BAD THING) which implies that you are: a. logging in as root and starting tomcat OR b. letting tomcat be started by a sys init process. One decision you must make is whether or not tomcat should be allowed to access privileged ports (eg port 80) If so, then you should start tomcat using something like jsvc (see http://commons.apache.org/daemon/index.html) which when properly configured will allow you to start an app as root, bind tomcat to port 80 and then switch to a 'tomcat' user. You can set umask permissions as appropriate in the startup script. If you intend to run tomcat with its default port of 8080 (or any non-privileged port) things are a bit simpler. Create a user on your system (maybe 'mytomcat') and then simply start the tomcat ./bin/startup.sh as this user by something like: su mytomcat -c $JAVA_HOME/bin/startup.sh from within the init script. You can, of course, su to the user you are running the other java program as, then tomcat and your app will have the same user privileges - or you can create a tomcat group, make this the main group for your tomcat user, add it as another group to your 'application' user and set the appropriate umask (002) to allow group read/write (you must also set the directory permissions accordingly - set the 's' bit) Please note that these are only pointers not a rigorous set of instructions. The reality is that if you want to do anything serious in linux you must learn ins and outs of 'bash' and this list is not really the place to do that. HTH Alan Daniel J Hulme wrote: Alan, this is very useful, thank you. After a bit of Googling I decided to upgrade to Tomcat6 (apparently is has less security ussies with Ubuntu). This means that the files/dirs are now created (from the tomcat app) by 'root:root' (with the same permissions described in my first post). However, I still have the same problem. I'm running a java progam (not as 'root'), and need write access to these files. And I'm not allowed to run my java app as 'root'. I'm pretty new to linux, so your help (i.e. command examples) is much appreciated. Daniel Alan Chaney wrote: This is really a linux permissions issue. How are you starting tomcat? with the $TOMCAT_HOME/bin/startup.sh or with jsvc or are you using an ubuntu startup script? You don't say anything about the user who will run the java application. Generally, the way to control the access permissions with which files are created in linux is to call 'umask' with the correct parameters. As mentioned before on this list umask is a shell command, so you must do it at the correct point or severely weaken the overall security of your installation. You need to do the following: 1. decide which user or users will be executing tomcat and the java application. 2. If you decide that you need to have two separate users, then make them both in the same group. 3. Use umask in the tomcat startup script and/or the shell in which you run your application to set appropriate access permissions - GIYF As an aside, if you are going to have two different processes writing these shared files you may also have to consider locking issues - maybe you have already done this. Regards Alan Chaney Daniel J Hulme wrote: Hi, I'm running a WebService using Tomcat 5.5 on Ubuntu 7.10 with Axis2. Files (and directories) are created by this service on a local directory: /myfiles/ The permission of the new directories and files in this directory are: Directories: 'drwxr-xr-x 2 tomcat55 nogroup 4096' Files: '-rw-r--r-- 1 tomcat55 nogroup 10041' The problem is, is I want to access (write) these files using, say, a java application, it give me: java.io.FileNotFoundException: /myfiles/aDir/aFile.txt (Permission denied
permissions to read/write files outside webapps directory?
Hi,
I've just deployed my webapp on the remote server (tomcat5 and red hat
linux) - everything is displaying properly but when the user uploads a file
for processing it is failing - looking in the log files it appears that
tomcat can't read or write files outside the webapps directory by these
error messages:
java.io.FileNotFoundException:
/home/kimberly/test/cases/85/85-settings.txt(Permission denied)
Permissions on this directory are readable by everyone and I thought tomcat
would be able to write/read to the tomcat5/temp directory but that doesn't
appear to be happening either.
I want it to read 1000's of files from my home directory and when uploading
files to write them to the temp file in /usr/share/tomcat5/temp/test. This
works great on my local copy but isn't working on the remote server.
So from what I gather online I need to edit the catalina.policies file to
allow read/write access to the appropriate directories. Before I go messing
around with the policies file for the first time I wanted to double check
that this is appropriate as well as check the syntax.
// Example policy file entry
grant [signedBy signer,] [codeBase code source] {
permission class [name [, action list]];
};
So syntax would be something like:
grant codeBase file:${catalina.home}/temp permission
java.io.FilePermission, read,write;
grant codeBase file:/home/kimberly/test/cases
permission.java.io.FilePermission, read;
And then do I just restart tomcat?
Please any advice would be greatly appreciated.
Thanks!
Re: War File Deployment - Permissions for ftp account
Thanks for your suggests Juha. Managed it by using ACLs. Default group rights are rw now for the webapps folder and Tomcat is unpacking with rw for the group now. I will check the umask from tomcat in the evening, but the ACL solution seems to be quicker and safer, because I can set the permissions for every virtual host if I've got the need for it and leave the default permissions for those who don't need this feature. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
War File Deployment - Permissions for ftp account
First of all, everything is fine with the unpacking of the War file. But I need a safe concept for a ftp user which should upload, delete and manage the War file/Application. Tomcat 5.5 is running with tomcat:tomcat Ftpuser is ftpuser:tomcat The webapps directory has ownership ftpuser:tomcat, group permission for tomcat is rwx. After uploading the war per ftp, tomcat is unpacking the war file in the webapps folder in a subdirectory. Everything is accessible and works, fine. If the ftpuser deletes the war file, tomcat is deleting the application subdirectory, fine. In some circumstances it will be important for the ftp user to do some changes to the unpacked application (mostly change some values in xml files or altering some jsps), leaving the rest of the application untouched. Tomcat is extracting the War file with tomcat:tomcat, but with group permission read only for group. So the ftpuser belonging to group tomcat has no chance to alter any files, bad. So I`ve got some questions: Is it possible to unpack a war file always with group permission read/write? Is there a way telling tomcat to extract war files with ownership ftpuser:tomcat? Everything could be done by changing permissions with chown or chmod, but the ftpuser has no bash, and a cronjob would be the last thing I want to do. Thank you for your suggests - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: War File Deployment - Permissions for ftp account
Carsten Schmitz wrote: But I need a safe concept for a ftp user which should upload, delete and manage the War file/Application. Tomcat 5.5 is running with tomcat:tomcat Ftpuser is ftpuser:tomcat ... In some circumstances it will be important for the ftp user to do some changes to the unpacked application (mostly change some values in xml files or altering some jsps), leaving the rest of the application untouched. Tomcat is extracting the War file with tomcat:tomcat, but with group permission read only for group. So the ftpuser belonging to group tomcat has no chance to alter any files, bad. So I`ve got some questions: Is it possible to unpack a war file always with group permission read/write? Is there a way telling tomcat to extract war files with ownership ftpuser:tomcat? It might be that your tomcat is running with umask 022 (or 027); if so, this would by default strip write access from group (which most often is the correct thing to do), and write access or all access by others. If it is so, you could change your tomcat startup to set the umask to 002 or 007 (permit write access to group, but prohibit write or any access by others). If that doesn't help, then a lot depends on your OS platform; it could be that it supports filesystem ACLs beyond the standard unix file permissions, which would make it possible to set default permissions on directory trees, or even to add auxiliary group permissions, and make these inheritable to any objects created within the tree. But from within Tomcat, no way that I know of (short of diving into the code to find out where the WARs are exploded, and changing the file permissions there. -- ..Juha - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
upgrade to 5.5.25 causes java permissions issues
HI, I upgraded from 5.5.15 to 5.5.25 and now I'm getting errors relating to java security (I'm using security manager). It appears as if my catalina.policy is not longer being recognized, because I have clearly outlined the permissions for the webapps, like java.lang.RuntimePermission setContextClassLoader etc..., but I get access denied errors for all my existing permissions. Has the security configuration changed at all? Thanks -- Justin Kennedy Maritime Source, Inc. http://maritimesource.ca 506-696-1564 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: upgrade to 5.5.25 causes java permissions issues
Justin Kennedy wrote: HI, I upgraded from 5.5.15 to 5.5.25 and now I'm getting errors relating to java security (I'm using security manager). It appears as if my catalina.policy is not longer being recognized, because I have clearly outlined the permissions for the webapps, like java.lang.RuntimePermission setContextClassLoader etc..., but I get access denied errors for all my existing permissions. Has the security configuration changed at all? Not that I can recall. Neither do I see anything in the change log. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
Yes, I have added debug code to the Perl program, and where it stalls seems to be the following line: $myDatabase = new Win32::ODBC($data_source); It just keeps hanging at that line. If I go to Windows Task Manager, I see perl.exe running, but at a fixed memory space (no changes). Also, forcing perl.exe off the Task Manager unstalls the CGI program and it just prints all the debug comments up to the code I wrote above. Someone suggested that I switch to another JDK but our workplace uses only Sun JDK for production servers...any insights to resolving this other than writing a whole new module in Java? -Original Message- Date: Sun Oct 14 18:29:57 EDT 2007 From: Mark Thomas [EMAIL PROTECTED] Subject: Re: Perl Permissions on Tomcat To: Tomcat Users List users@tomcat.apache.org Li Ye Chen wrote: Script A (the problem script) continues to run after 2 minutes (with partial output some of the time). But script A ran under the command line (as opposed to the browser/Tomcat) is very fast -- under a second and gives full output. Script B runs under less than a second and gives full output. Sounds like you need to add some debugging to your script to figure out where the problem is. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
Li Ye Chen wrote: Script A (the problem script) continues to run after 2 minutes (with partial output some of the time). But script A ran under the command line (as opposed to the browser/Tomcat) is very fast -- under a second and gives full output. Script B runs under less than a second and gives full output. Sounds like you need to add some debugging to your script to figure out where the problem is. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
Yes, if you mean enabling the file server/lib/servlets-cgi.jar... -Original Message- Date: Mon Oct 09 18:25:12 EDT 2000 From: Martin Gainty [EMAIL PROTECTED] Subject: Re: Perl Permissions on Tomcat To: Tomcat Users List users@tomcat.apache.org I asked yesterday but didnt hear back..Are you implementing via CGIServlet? M-- - Original Message - From: Li Ye Chen [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, October 09, 2007 4:34 PM Subject: Re: Perl Permissions on Tomcat Okay, I did some searching on the Internet and found that according to current config in my Tomcat, it's not even running SecurityManager (the -Djava...securitymanager argument is not available in the Java tab of the Configuration screen. And it is still not working, so I'm not sure what is going on here... Any help will be appreciated! -Original Message- Date: Mon Oct 08 12:52:23 EDT 2007 From: Mark Thomas [EMAIL PROTECTED] Subject: Re: Perl Permissions on Tomcat To: Tomcat Users List users@tomcat.apache.org Li Ye Chen wrote: Will it pose a security risk if I disable the Security Manager? I am running an enterprise firewall on the server... That depends on your environment. But you have a separate machine for development and/or testing - right? Right now we need to figure out if it is the security manager causing the problem or something else. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
I assume it's a permission problem since: 1) I'm trying to run script A (the script with the problem), and 2) script B ran with no problems at all, but 3) script A also ran with no problems if executed from the command line directly instead of in the browser via Tomcat server... both scripts A and B are in the WEB-INF/cgi folder of a webapp in the Tomcat server. There are no error messages. Apparently, it may also be a speed issue, since there was once when I ran script A and after a while, I stopped the transmission -- there was actually a partial output from the script. -Original Message- Date: Tue Oct 09 16:54:50 EDT 2007 From: Christopher Schultz [EMAIL PROTECTED] Subject: Re: Perl Permissions on Tomcat To: Tomcat Users List users@tomcat.apache.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Li, Li Ye Chen wrote: Hi, I'm trying to run a Perl script on Tomcat 5.5.8 -- I've managed to successfully run read-only Perl script, but the script I'm trying to run connects to the database and needs to write to the local hard drive. Whenever I try to execute the script, it creates a Perl.exe thread on my Windows server and just never return the HTML code (so the browser keeps loading) -- it seems there is a permission problem. Why do you believe there is a permissions problem? If perl.exe is running, then you have permission to run perl.exe. If you don't have permission to read the script file, then you should be getting some kind of error message somewhere. Can you see any error messages anywhere? How are you trying to execute this perl script? Be specific. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHC+qa9CaO5/Lv0PARApzZAJsGg5LMZXycPyWTHUpbJ8cyk7mWrgCcDRPo Q+HJ78JMBbf3cDZsnbveV08= =IZrk -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
Li Ye Chen wrote: Apparently, it may also be a speed issue, since there was once when I ran script A and after a while, I stopped the transmission -- there was actually a partial output from the script. How long does script A take to run? Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl Permissions on Tomcat
I'm running Tomcat on Windows XP, and in my Configuration - Startup menu, the
entry for the Arguments text box is start, with no other string (nothing that
says -security). Does that mean I'm currently running without SecurityManager?
-Original Message-
Date: Mon Oct 08 12:03:37 EDT 2007
From: Mark Thomas [EMAIL PROTECTED]
Subject: Re: Perl Permissions on Tomcat
To: Tomcat Users List users@tomcat.apache.org
Li Ye Chen wrote:
// Give all permission to servlets-cgi.jar
grant codeBase file:${catalina.home}/server/lib/servlets-cgi.jar {
permission java.security.AllPermission;
};
Are you running with a security manger? If so, try running without and
get things working that way first. Then we can focus on the permissions.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
