search

atsign-foundation / noports

Connect to any device with no external listening ports open
https://noports.com
BSD 3-Clause "New" or "Revised" License
263 stars 15 forks source link

fix: noports_core .ssh directory owned by root causing issues #1167

Closed Xlin123 closed 1 week ago

Xlin123 commented 1 week ago

Describe the bug

sshnp -t @bagel69 -f @almond842 -r @rv_am -d apaz

Error : Error: 1 Operation not permitted Message: chown failed error: Operation not permitted

Stack Trace: #0 chmod (package:posix/src/unistd/unistd.dart:409)

1 new LocalSshKeyUtil (package:noports_core/src/common/at_ssh_key_util/local_ssh_key_util.dart:41)

2 new _SshnpOpensshLocalImpl&SshnpCore&SshnpLocalSshKeyHandler (package:noports_core/src/sshnp/impl/sshnp_openssh_local_impl.dart:10)

3 new SshnpOpensshLocalImpl (package:noports_core/src/sshnp/impl/sshnp_openssh_local_impl.dart)

4 new Sshnp.openssh (package:noports_core/src/sshnp/sshnp.dart:28)

5 createSshnp (package:sshnoports/src/create_sshnp.dart:28)

#6 main. (file:///home/runner/work/noports/noports/packages/dart/sshnoports/bin/sshnp.dart:147) #7 main (file:///home/runner/work/noports/noports/packages/dart/sshnoports/bin/sshnp.dart:96) drwx------- 2 root root 4096 May 30 14:39 .ssh drwx----- 5 xavier xavier 4096 Jun 3 14:59 .sshnp ### Steps to reproduce 1. First, chown root .ssh folder 2. Then I sshnp command 3. Error pops up. ### Expected behavior provide an error message saying “.ssh or .sshnp is owned by root, please chown this directory” ### Screenshots _No response_ ### Smartphones - OS: Windows(WSL), Fedora - Version v5.5.0 ### Were you using an atApplication when the bug was found? _No response_ ### Additional context _No response_
XavierChanth commented 1 week ago

we should ideally chown it and if not permitted, abort with a message saying “please sudo chown this directory”

I don't think sshnp should do this, for a few reasons:

  1. The $USER running sshnp, should already own $HOME/.ssh, and if they don't, then the environment is messed up and it's not within the scope of our application.

  2. This code shouldn't be executed with the v5.3.0 & later client with a v5.3.0 & later / C daemon. We only kept this code for backward compatibility with older daemons

gkc commented 1 week ago

we should ideally chown it and if not permitted, abort with a message saying “please sudo chown this directory”

I don't think sshnp should do this, for a few reasons:

  1. The $USER running sshnp, should already own $HOME/.ssh, and if they don't, then the environment is messed up and it's not within the scope of our application.

I think a helpful error message is required. And in this case, wasn't the environment messed up by the sshnp installer?

  1. This code shouldn't be executed with the v5.3.0 & later client with a v5.3.0 & later / C daemon. We only kept this code for backward compatibility with older daemons

Good point