[GitHub] [mina-sshd] ramasubbaiya opened a new issue, #406: Enabling user level permissions

2023-08-24 Thread via GitHub


ramasubbaiya opened a new issue, #406:
URL: https://github.com/apache/mina-sshd/issues/406

   ### Description
   
   We have an Apache MINA SFTP server that uses a user table to authenticate 
users. We would like to setup permissions such as LIST, DOWNLOAD, UPLOAD, and 
others, where users are only allowed to perform certain actions based on their 
permissions.
   
   We would appreciate any ideas or recommendations on how to enable this.
   
   ### Motivation
   
   Implementing user-level permissions to restrict users based on their 
usernames/account.
   
   ### Alternatives considered
   
   _No response_
   
   ### Additional context
   
   _No response_


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[GitHub] [mina-sshd] tomaswolf commented on issue #403: exceptionCaught(ServerSessionImpl[user@/10.x.x.x:23232])[state=Opened] IllegalStateException: Bad length (32796) for cmd=SSH_MSG_CHANNEL_DATA -

2023-08-24 Thread via GitHub


tomaswolf commented on issue #403:
URL: https://github.com/apache/mina-sshd/issues/403#issuecomment-1692304267

   @dragonknight88 : PR #405 has been merged. Using the 2.10.1-SNAPSHOT release 
from the [Apache Snapshot maven 
repository](https://repository.apache.org/content/repositories/snapshots) you 
could test whether it really works with WS_FTP with different handle sizes. If 
not, feel free to re-open this.
   
   Ultimately it would be good if the vendor of WS_FTP fixed that bug in their 
SFTP client.


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[GitHub] [mina-sshd] tomaswolf closed issue #403: exceptionCaught(ServerSessionImpl[user@/10.x.x.x:23232])[state=Opened] IllegalStateException: Bad length (32796) for cmd=SSH_MSG_CHANNEL_DATA - max.

2023-08-24 Thread via GitHub


tomaswolf closed issue #403: 
exceptionCaught(ServerSessionImpl[user@/10.x.x.x:23232])[state=Opened] 
IllegalStateException: Bad length (32796)  for cmd=SSH_MSG_CHANNEL_DATA - max. 
allowed=32768
URL: https://github.com/apache/mina-sshd/issues/403


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[GitHub] [mina-sshd] tomaswolf merged pull request #405: Fix SFTP file handles

2023-08-24 Thread via GitHub


tomaswolf merged PR #405:
URL: https://github.com/apache/mina-sshd/pull/405


-- 
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.

To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object

2023-08-24 Thread Alexander B (Jira)


[ 
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758563#comment-17758563
 ] 

Alexander B commented on DIRMINA-1172:
--

Actually, the two Cmd's are running in parallel. 

But, anyway, I think, if it works now - would it be possible to fix this 
officially in 2.1.x and/or 2.2.x ?

Thanks a lot

> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java, 
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created 
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP = 
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor) 
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE, 
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
>   ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
>   log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send 
> UDP packages (from a external application) to both ports (independently). It 
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws 
> Exception {
>   String msgStr = message.toString();
>   log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1 
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2 
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1. 
> If I do exactly the same with `NioSocketConnector`, I can see two different 
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1 
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2 
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor? 
> Or is there any setting, such that DatagramAcceptors can create/handle their 
> own session objects?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object

2023-08-24 Thread Jira


[ 
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758540#comment-17758540
 ] 

Emmanuel Lécharny commented on DIRMINA-1172:


The session does not last forever, may be it expired in scenario 2?

> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java, 
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created 
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP = 
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor) 
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE, 
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
>   ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
>   log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send 
> UDP packages (from a external application) to both ports (independently). It 
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws 
> Exception {
>   String msgStr = message.toString();
>   log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1 
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2 
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1. 
> If I do exactly the same with `NioSocketConnector`, I can see two different 
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1 
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2 
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor? 
> Or is there any setting, such that DatagramAcceptors can create/handle their 
> own session objects?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object

2023-08-24 Thread Alexander B (Jira)


[ 
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758460#comment-17758460
 ] 

Alexander B commented on DIRMINA-1172:
--

Actually, I still did not get the clue. Before, the port was not part of the 
session key. And scenario 2 worked before. It was just scenario 3, that did not 
work. Scenario 2 and 3 are both sending to different ports. The difference is 
just from two applications or just from one. In both scenarios you can find 
just one sending machine.

> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java, 
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created 
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP = 
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor) 
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE, 
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
>   ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
>   log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send 
> UDP packages (from a external application) to both ports (independently). It 
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws 
> Exception {
>   String msgStr = message.toString();
>   log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1 
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2 
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1. 
> If I do exactly the same with `NioSocketConnector`, I can see two different 
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1 
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2 
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor? 
> Or is there any setting, such that DatagramAcceptors can create/handle their 
> own session objects?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object

2023-08-24 Thread Jira


[ 
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758452#comment-17758452
 ] 

Emmanuel Lécharny commented on DIRMINA-1172:


Hi, Alexender,

they do have the same IP address, but they aren't sending the data to the same 
port. Now that the port is part of the session key, two sessions will be 
created.

> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java, 
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created 
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP = 
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor) 
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE, 
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
>   ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
>   log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send 
> UDP packages (from a external application) to both ports (independently). It 
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws 
> Exception {
>   String msgStr = message.toString();
>   log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1 
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2 
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1. 
> If I do exactly the same with `NioSocketConnector`, I can see two different 
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1 
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2 
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor? 
> Or is there any setting, such that DatagramAcceptors can create/handle their 
> own session objects?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object

2023-08-24 Thread Alexander B (Jira)


[ 
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758431#comment-17758431
 ] 

Alexander B commented on DIRMINA-1172:
--

Thanks a lot - i think my three scenarios are working fine now.

What I actually don't understand is the second scenario: There are two Cmds 
from one machine sending to a target machine. For me it seems that these 
senders should have the same remote address - don't they? Why did this work 
before as well? Just the case sending to two different ports from one 
application (on one machine) to one target machine seems to be problematic?

> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java, 
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created 
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP = 
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor) 
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE, 
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
>   ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
>   log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send 
> UDP packages (from a external application) to both ports (independently). It 
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws 
> Exception {
>   String msgStr = message.toString();
>   log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1 
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2 
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1. 
> If I do exactly the same with `NioSocketConnector`, I can see two different 
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1 
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2 
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor? 
> Or is there any setting, such that DatagramAcceptors can create/handle their 
> own session objects?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org