Re: Issue with Chunked encoding in tomcat/tomee with a specific file
my apologies for the delayed response in sharing the sample program source code. I created a git repository with just 2 files, One for client code and the other for server. These are source files for the class files shared in the first attachment. https://github.com/sreeharshamunagala/ChunkedEncoding Let me know if this is accessible and if anything else helps for troubleshooting. -- Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
Re: Docker Images on Dockerhub
Hi Rod, I am certainly willing to talk about this via Skype or similar. I take no offense to a differing position on the desired used of running a process as an arbitrary UID. I came along in a time when if you ran as root or even did a sudo command you should have a good reason and be aware of what you were doing so that you did not accidentally do an "rm -Rf" or the like on some non-user directory of importance. Having said that, I believe the idea of running any process as a user that one cannot (hopefully) predict as a more secure approach may sound a bit paranoid (I am guessing the above statement does as well to some). The best explanation I have for the concern is italicized below from some of Red Hat's docs on OpenShift: *Running processes for applications as different user IDs means that if a security vulnerability were ever discovered in the underlying container runtime, and an application were able to break out of the container to the host, they would not be able to interact with processes owned by other users, or from other applications, in other projects.Use of assigned user IDs is a part of the multi layer security strategy employed by OpenShift to reduce risks were an application or the container runtime compromised.* On the other hand, if containers are running on one or more hosts or k8s clusters and they all have the same UID, there is certainly the potential for additional harm should a vulnerability exist. If the UID happens to be common (perhaps tomcat, apache, mysql, all run as 1001 in different images/containers/versions by design for some), there is more risk potential (that's probably a bit of a stretch and hopefully not actually happening). Let me know if you would like to talk. If you'd rather abandon the whole notion of support for running as an arbitrary UID, I certainly understand and respect that position. I won't be able to use the resulting images in most of my current use cases but I get it and can adjust accordingly as needed. Regards, Carl On Mon, Nov 25, 2019 at 7:20 PM Jenkins, Rodney J (Rod) < jenki...@nationwide.com> wrote: > Carl, > > I also had issues posting to the group on Friday night/Saturday morning. > > I fear that we are talking past one another. I will try to be much > clearer in my responses. If we cannot resolve this via email, I am willing > to host a Skype session to talk through. Anyone on the list would be > welcome to join. > > We agree on the "why" running on anything other than root is a good idea. > I think we are discussing more about the "how to" run on some other ID. > What I did not understand is "why" you handle it the way you do. > > Also, I would like to pre-apologize if I am talking down to you or anyone. > > You say, "We don't know the UID until runtime." I am not sure why you > would want to know what that UID is at all or ever. The /etc/passwd > convers the username to the UID. The nice thing about Tomcat/TomEE, it > runs as the user that calls it. As long as java is available, it will > start. > > You propose that in order to create that specific user and start TomEE as > that user, you do the following: > 1) Alter the /etc/passwd file to have group write access > 2) Altering catalina.sh to add the user to /etc/passwd > 3) Setting the ownership of the /usr/local/tomee to UID:root > 4) Setting permissions of all files and directories in /usr/local/tomee to > g=u > 5) "USER" 1001 in the Dockerfile > 6) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start > TomEE as the UID set in #5 > 7) When Catalina.sh is run, it adds the user to the passwd file, then > starts TomEE as UID 1001, in your case with the user tomee. > > I propose the following to create the user and start TomEE > 1) useradd in the Dockerfile to create the user tomee in the /etc/passwd > file > 2) "USER tomee" in the Dockerfile > 3) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start > TomEE as the UID set in #2 > > To be clear, I have no pony in this race other than finding the best way. > If I am wrong, I have learned something valuable! > > If you would like you can see my Dockerfiles in tomitribe/docker-tomee, > grab them and run some tests. Some hosting providers have specific > requirements for running as a user other than root. Maybe, that is why > Tomcat has decided to sidestep the whole discussion and run as root out of > the box and let the user sort it out. Maybe, we should do the same. While > it is a security issue, it becomes a default standard issue to try to fix. > > Have a nice day!! > Rod. > > > > > > > > On 11/25/19, 4:01 PM, "Carl Mosca" wrote: > > > Hi Rod, > > I am seeing some of my messages bouncing back - perhaps they are too > long > so I apologize if this was already sent: > > I am not sure if you're asking "why" I think it's a good idea to run > as an > arbitrary UID or the "why" behind what's going on with doing so...I > try to > touch on all of it: > > We don
Re: Docker Images on Dockerhub
Carl, I also had issues posting to the group on Friday night/Saturday morning. I fear that we are talking past one another. I will try to be much clearer in my responses. If we cannot resolve this via email, I am willing to host a Skype session to talk through. Anyone on the list would be welcome to join. We agree on the "why" running on anything other than root is a good idea. I think we are discussing more about the "how to" run on some other ID. What I did not understand is "why" you handle it the way you do. Also, I would like to pre-apologize if I am talking down to you or anyone. You say, "We don't know the UID until runtime." I am not sure why you would want to know what that UID is at all or ever. The /etc/passwd convers the username to the UID. The nice thing about Tomcat/TomEE, it runs as the user that calls it. As long as java is available, it will start. You propose that in order to create that specific user and start TomEE as that user, you do the following: 1) Alter the /etc/passwd file to have group write access 2) Altering catalina.sh to add the user to /etc/passwd 3) Setting the ownership of the /usr/local/tomee to UID:root 4) Setting permissions of all files and directories in /usr/local/tomee to g=u 5) "USER" 1001 in the Dockerfile 6) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start TomEE as the UID set in #5 7) When Catalina.sh is run, it adds the user to the passwd file, then starts TomEE as UID 1001, in your case with the user tomee. I propose the following to create the user and start TomEE 1) useradd in the Dockerfile to create the user tomee in the /etc/passwd file 2) "USER tomee" in the Dockerfile 3) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start TomEE as the UID set in #2 To be clear, I have no pony in this race other than finding the best way. If I am wrong, I have learned something valuable! If you would like you can see my Dockerfiles in tomitribe/docker-tomee, grab them and run some tests. Some hosting providers have specific requirements for running as a user other than root. Maybe, that is why Tomcat has decided to sidestep the whole discussion and run as root out of the box and let the user sort it out. Maybe, we should do the same. While it is a security issue, it becomes a default standard issue to try to fix. Have a nice day!! Rod. On 11/25/19, 4:01 PM, "Carl Mosca" wrote: Hi Rod, I am seeing some of my messages bouncing back - perhaps they are too long so I apologize if this was already sent: I am not sure if you're asking "why" I think it's a good idea to run as an arbitrary UID or the "why" behind what's going on with doing so...I try to touch on all of it: We don't know the UID until runtime (but we do know that user will be in the root group). While I acknowledge that this seems clumsy at first, and I am far from a security expert, it does seem more secure to me if one cannot predict the runtime UID as Red Hat describes in the OCP docs. If one is always using the *same known* UID, I think the attack surface changes a bit. If there is a need or desire in any given container/application to make that unknown UID be a particular user I see two options: One, we can change an already existing user which can be messy/hard/impossible depending file/directory ownership needs that are required for some applications and order of installation operations. (When I say impossible I am thinking of a particular situation I bumped into which is admittedly a corner case and most likely not applicable here.) The second option is just wait to create the user at runtime. Given the permission changes, we can modify /etc/passwd as described, which results in the creation of the user. In addition, other "chmod g=u" operations are what allows us to take ownership of other files/directories if/as needed at runtime. There are certainly situations where the username simply does not matter and the arbitrary UID in root group is used then there's no need to add a user. HTH, Carl
Re: Docker Images on Dockerhub
Hi Rod, I am seeing some of my messages bouncing back - perhaps they are too long so I apologize if this was already sent: I am not sure if you're asking "why" I think it's a good idea to run as an arbitrary UID or the "why" behind what's going on with doing so...I try to touch on all of it: We don't know the UID until runtime (but we do know that user will be in the root group). While I acknowledge that this seems clumsy at first, and I am far from a security expert, it does seem more secure to me if one cannot predict the runtime UID as Red Hat describes in the OCP docs. If one is always using the *same known* UID, I think the attack surface changes a bit. If there is a need or desire in any given container/application to make that unknown UID be a particular user I see two options: One, we can change an already existing user which can be messy/hard/impossible depending file/directory ownership needs that are required for some applications and order of installation operations. (When I say impossible I am thinking of a particular situation I bumped into which is admittedly a corner case and most likely not applicable here.) The second option is just wait to create the user at runtime. Given the permission changes, we can modify /etc/passwd as described, which results in the creation of the user. In addition, other "chmod g=u" operations are what allows us to take ownership of other files/directories if/as needed at runtime. There are certainly situations where the username simply does not matter and the arbitrary UID in root group is used then there's no need to add a user. HTH, Carl
[GitHub] [tomee] cesarhernandezgt merged pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms
cesarhernandezgt merged pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms URL: https://github.com/apache/tomee/pull/611 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [tomee] jgallimore commented on issue #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl
jgallimore commented on issue #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl URL: https://github.com/apache/tomee/pull/613#issuecomment-558266208 I'll merge this in, and we'll let the CI build it. Hopefully all will look good, but we'll revisit it if we see tests failing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [tomee] jgallimore merged pull request #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl
jgallimore merged pull request #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl URL: https://github.com/apache/tomee/pull/613 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [GitHub] [tomee] cocorossello commented on issue #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl
I think the nightly CI uses Java 8, isn't that right, @Jonathan Gallimore ? So if its passing can we assume that the PR is good to go? On Mon, Nov 25, 2019 at 10:04 AM GitBox wrote: > cocorossello commented on issue #613: TOMEE-2744: JD14 compatibility: > remove usage of javax.security.acl > URL: https://github.com/apache/tomee/pull/613#issuecomment-558222651 > > >Hi, > >In the code acl.Group is used basically as a Principal with members > support, is not used as a Policy, as far as I can see. > >With this change our environment works in jdk11, 12, 13 and 14, I > don't see any reason why it wouldn't work in jdk8 (but of course I don't > know all the use cases here). > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > > With regards, > Apache Git Services > -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
[GitHub] [tomee] cocorossello commented on issue #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl
cocorossello commented on issue #613: TOMEE-2744: JD14 compatibility: remove usage of javax.security.acl URL: https://github.com/apache/tomee/pull/613#issuecomment-558222651 Hi, In the code acl.Group is used basically as a Principal with members support, is not used as a Policy, as far as I can see. With this change our environment works in jdk11, 12, 13 and 14, I don't see any reason why it wouldn't work in jdk8 (but of course I don't know all the use cases here). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [tomee] cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms
cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms URL: https://github.com/apache/tomee/pull/611#discussion_r350243284 ## File path: examples/simple-jms/README_es.adoc ## @@ -0,0 +1,253 @@ +:index-group: JMS and MDBs +:jbake-type: page +:jbake-status: status=published + += Simple JMS + +Este ejemplo demuestra cómo configurar un servicio JMS personalizado ``CustomJmsService`` +para producir y consumir un Mensaje JMS ``Message``. + += Codigo Review comment: Código This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [tomee] cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms
cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add
Spanish translation for simple-jms
URL: https://github.com/apache/tomee/pull/611#discussion_r350244283
##
File path: examples/simple-jms/README_es.adoc
##
@@ -0,0 +1,253 @@
+:index-group: JMS and MDBs
+:jbake-type: page
+:jbake-status: status=published
+
+= Simple JMS
+
+Este ejemplo demuestra cómo configurar un servicio JMS personalizado
``CustomJmsService``
+para producir y consumir un Mensaje JMS ``Message``.
+
+= Codigo
+
+== El servicio JMS: ``Message``, ``Queue``, MessageProducer``,
``MessageConsumer``
+
+Aquí tenemos un punto final REST, una clase con la anotacion: ``@Path("/
message")`` que indica la ruta correspondiente a la clase ``CustomJmsService``.
Por lo tanto, definimos ``sendMessage()`` como ``@POST`` y ``acceptMessage()``
como ``@GET`` para la ruta ``/message``.
+
+Además, directamente relacionado con este ejemplo, se pueden observar 2
elementos: una cola: ``Queue`` y una fabrica de conexiones:
``ConnectionFactory`` anotadas como ``@Resource``
+
+Finalmente, interactuando con instancias de ``Connection``, ``Session``, y
``Queue`` se pueden ver instancias de ``MessageProducer`` y
``MessageConsumer``, responsables de escribir y leer hacia la / desde la cola:
``Queue`` respectivamente.
+
+
+@Stateless
+@Path("message")
+public class CustomJmsService {
+
+@Resource(name = "messageQueue")
+private Queue messageQueue;
+
+@Resource
+private ConnectionFactory connectionFactory;
+
+@POST
+public void sendMessage(final String message) {
+sendMessage(messageQueue, message);
+}
+
+@GET
+public String receiveMessage() throws JMSException {
+final TextMessage textMessage = receiveMessage(messageQueue, 1000);
+if (textMessage == null) {
+return null;
+}
+
+return textMessage.getText();
+}
+
+private void sendMessage(final Queue queue, final String message) {
+try (final Connection connection =
connectionFactory.createConnection();
+ final Session session = connection.createSession(true,
Session.AUTO_ACKNOWLEDGE);
+ final MessageProducer producer = session.createProducer(queue)) {
+
+connection.start();
+
+final Message jmsMessage = session.createTextMessage(message);
+
+// This enqueues messages successfully with both 8.0.0-M3 and 8.0.0
+producer.send(jmsMessage);
+} catch (final Exception e) {
+throw new RuntimeException("Caught exception from JMS when sending
a message", e);
+}
+}
+
+private TextMessage receiveMessage(final Queue queue, final long
receiveTimeoutMillis) {
+try (final Connection connection =
connectionFactory.createConnection();
+ final Session session = connection.createSession(true,
Session.AUTO_ACKNOWLEDGE);
+ final MessageConsumer messageConsumer =
session.createConsumer(queue)) {
+
+connection.start();
+
+final Message jmsMessage =
messageConsumer.receive(receiveTimeoutMillis);
+
+if (jmsMessage == null) {
+return null;
+}
+
+return (TextMessage) jmsMessage;
+} catch (final Exception e) {
+throw new RuntimeException("Caught exception from JMS when
receiving a message", e);
+}
+}
+}
+
+
+
+== Probando
+
+=== Test para el servicio JMS
+
+La prueba es trivial. La idea consiste en hacer primero una petición POST que
contiene el mensaje para el servicio. Esto se realiza usando instancias de las
clases ``ClientBuilder`` y ``WebTarget``.
+
+Luego, de manera similar a la petición POST, se lleva a cabo una petición GET
que consume el mensaje anterior.
+
+Finalmente, se verifican los HTTP status de las respuestas de manera que sean
equivalentes a los códigos HTTP esperados (204/200), así como también que el
contenido del mensaje recibido sea igual al mensaje enviado.
+
+
+
+@RunWith(Arquillian.class)
+@RunAsClient
+public class CustomJmsServiceTest {
+
+@Deployment
+public static Archive deployment() {
+return Mvn.war();
+}
+
+@ArquillianResource
+private URL baseUrl;
+
+@Test
+public void test() throws Exception {
+// POST
+{
+final WebTarget webTarget =
ClientBuilder.newClient().target(baseUrl.toURI());
+final Response response =
webTarget.path("message").request().post(Entity.text("This is a test"));
+
+assertEquals(204, response.getStatus());
+}
+
+// GET
+{
+final WebTarget webTarget =
ClientBuilder.newClient().target(baseUrl.toURI());
+final Response response =
webTarget.path("message").request().get();
+assertEquals(200, response.getStatus());
+
+final String content = response.readEntity(String.class);
+assertEquals("This is a
[GitHub] [tomee] cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add Spanish translation for simple-jms
cesarhernandezgt commented on a change in pull request #611: [TOMEE-2742] Add
Spanish translation for simple-jms
URL: https://github.com/apache/tomee/pull/611#discussion_r350243707
##
File path: examples/simple-jms/README_es.adoc
##
@@ -0,0 +1,253 @@
+:index-group: JMS and MDBs
+:jbake-type: page
+:jbake-status: status=published
+
+= Simple JMS
+
+Este ejemplo demuestra cómo configurar un servicio JMS personalizado
``CustomJmsService``
+para producir y consumir un Mensaje JMS ``Message``.
+
+= Codigo
+
+== El servicio JMS: ``Message``, ``Queue``, MessageProducer``,
``MessageConsumer``
+
+Aquí tenemos un punto final REST, una clase con la anotacion: ``@Path("/
message")`` que indica la ruta correspondiente a la clase ``CustomJmsService``.
Por lo tanto, definimos ``sendMessage()`` como ``@POST`` y ``acceptMessage()``
como ``@GET`` para la ruta ``/message``.
Review comment:
anotación
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
Re: Help, not found issues for resolved
Hi Sergio, Thanks for your help! You can filter the JIRA for tickets that are not yet assigned to someone using advanced search. Click on the "Advanced Search" link on the far right at the top of the JIRA list for TomEE and enter the following: project = TOMEE AND resolution = Unresolved AND assignee is EMPTY ORDER BY priority DESC, updated DESC On Sat, Nov 23, 2019 at 7:21 AM Sergio Chancay wrote: > Hi, > > Not found issues for resolved, I found in > https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2200?filter=allopenissues > < > https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2200?filter=allopenissues> > but all is assigned or resolved with PR. > > Help me with any list o task for resolved. > > Thanks. -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
[GitHub] [tomee] jgallimore commented on issue #611: [TOMEE-2742] Add Spanish translation for simple-jms
jgallimore commented on issue #611: [TOMEE-2742] Add Spanish translation for simple-jms URL: https://github.com/apache/tomee/pull/611#issuecomment-558172352 Could we get a Spanish speaker to review? @cesarhernandezgt ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
