Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

various small fixes #1151

Merged
merged 19 commits into from
Apr 18, 2022
Merged

various small fixes #1151

merged 19 commits into from
Apr 18, 2022

Conversation

0pcom
Copy link
Collaborator

@0pcom 0pcom commented Apr 11, 2022

Changes:

  • fix hidden flags nil pointer error on mac & windows ( --all flag error)
  • optimized run-source & run-vpnsrv makefile directives and related subdirectives
  • fix visor read config from stdin for systray

On that last one, runVisor now can accept a config passed to it as input (or nil). Running with systray was trying to read the config a second time, calling for initConfig . When the config comes via stdin there is no second read possible.

Additions:

  • prepare and prepare-systray makefile directives
  • run-systray makefile directive
  • run-systray-test makefile directive

How to test this PR:

make run-systray-test

@0pcom
Copy link
Collaborator Author

0pcom commented Apr 11, 2022

In tests I discovered that the systray app is not appropriate to run as root on linux and does not function as intended. It possibly could but it cannot directly launch the browser as root. I have disabled systray if the root user is detected on macOS or linux.

privilege elevation for the vpn client / server is still yet to be addressed.

local/.gitignore Outdated Show resolved Hide resolved
@ersonp
Copy link
Contributor

ersonp commented Apr 12, 2022

In tests I discovered that the systray app is not appropriate to run as root on linux and does not function as intended. It possibly could but it cannot directly launch the browser as root. I have disabled systray if the root user is detected on macOS or linux.

privilege elevation for the vpn client / server is still yet to be addressed.

we need to set cap_net_admin by sudo setcap 'cap_net_admin+p' ./apps/vpn-client and sudo setcap 'cap_net_admin+p' ./apps/vpn-server

andi think we should provide a WARN log in case if the systray app is started as root.

cmd/apps/skysocks-client/skysocks-client.go Outdated Show resolved Hide resolved
cmd/apps/skychat/skychat.go Outdated Show resolved Hide resolved
cmd/apps/vpn-client/vpn-client.go Outdated Show resolved Hide resolved
cmd/apps/vpn-client/vpn-client.go Outdated Show resolved Hide resolved
cmd/apps/skychat/skychat.go Outdated Show resolved Hide resolved
@ersonp
Copy link
Contributor

ersonp commented Apr 12, 2022

One small change is needed for skywire windows. In windows config gen the only app that needs to be included is vpn-client as all other apps are not supported.

0pcom added 2 commits April 12, 2022 14:11
… are not found at path specified in config during config gen with small exceptions
… are not found at path specified in config during config gen with small exceptions
@0pcom
Copy link
Collaborator Author

0pcom commented Apr 12, 2022

On the systray app I changed the behavior from being disabled as root to only hiding the buttons that launch the browser when the process is run as root.

on the config gen @ersonp I changed it to detect if the applications are at the bin path, and if not they are added to the list of apps to disabled

exceptions to this behavior are in two instances;

  • the config is being written to stdout (-n flag)
  • the cli command was started with go run

most of the other stuff mentioned has been cleaned up

0pcom added 3 commits April 12, 2022 14:30
… as root to non root-owned path and fail before attempted non-root write to root-owned path for skywire-cli config gen and skywire-visor
… as root to non root-owned path and fail before attempted non-root write to root-owned path for skywire-cli config gen and skywire-visor
@0pcom
Copy link
Collaborator Author

0pcom commented Apr 13, 2022

I've prevented writing to non-root owned path as root and vice versa. With skywire-cli config gen and with skywire-visor

@ersonp I had to revert the -o flag for config gen to the way I had it before your recent PR.

At issue is flags.Changed not working right.. my workaround was to have the output be actually unset and set the value after it's detected that it contains an empty string, as well as to record that it was unset into a boolean to be used for overriding the output of the -p flag default config path

I was otherwise unable to get the -o flag to override the -p flag for config gen.

Tomorrow I need to add a flag which will generate one default config at a set location in the user space, which references the users.db and local folder along the same path as the config.

@ersonp
Copy link
Contributor

ersonp commented Apr 14, 2022

Can we just limit the scope of this PR to flags and reading from STDIN because the changes with the path is not actually solving the problem but just shifting it. I think it would be better if we fixed it via the read and write functions of all the files in the /local folder. If I remember correctly this issue was solved previously and only reappeared a little while ago (as far as I can tell). So I think it would be better if we took a deeper look at it in a different PR.

…ging more descriptive around these errors. Add dtection of unpublised changes since commit in logging
@0pcom
Copy link
Collaborator Author

0pcom commented Apr 14, 2022

@ersonp I've changed it to warn about writing with elevated permissions here:

image

I want to maintain the failure in the reverse instance as not failing means it runs but doesn't work, and just repeats "waiting for RPC get ready"

image

@@ -261,6 +335,32 @@ var genConfigCmd = &cobra.Command{
}
//don't write file with stdout
if !stdout {
thisUser, err := user.Current()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like userLvl or owner etc sounds better.

@@ -261,6 +335,32 @@ var genConfigCmd = &cobra.Command{
}
//don't write file with stdout
if !stdout {
thisUser, err := user.Current()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like userLvl or owner etc sounds better.

@@ -261,6 +335,32 @@ var genConfigCmd = &cobra.Command{
}
//don't write file with stdout
if !stdout {
thisUser, err := user.Current()
if err != nil {
panic(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What errors could this return? Are they clear enough in themselves? Should we exit cleanly and log something here instead?

@@ -261,6 +335,32 @@ var genConfigCmd = &cobra.Command{
}
//don't write file with stdout
if !stdout {
thisUser, err := user.Current()
if err != nil {
panic(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What errors could this return? Are they clear enough in themselves? Should we exit cleanly and log something here instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need to really error here & Ive changed it to fail transparently. This is only checking for root and it will just not change the default from false to true.

initQuitBtn()

go handleUserInteraction(conf, doneCh)
if checkRoot() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isRoot maybe clearer?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


func platformExecUninstall() error {
return osutil.Run("/bin/bash", "-c", deinstallerPath)
}

func checkRoot() bool {
thisUser, err := user.Current()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same suggestion as above. Using this sounds odd to me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

func checkRoot() bool {
thisUser, err := user.Current()
if err != nil {
panic(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to not panic here and log a fatal err with some context.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the logging overhead is unnecessary and it doesn't really need to fail, only to return true if root is detected.

this check is for limiting the available buttons in the systray to ones that are appropriate to launch by the current user. The browser won't be allowed to run as root in the userspace by the system, typically.

@@ -169,3 +169,9 @@ func Version() string {
}
return v
}

// HomePath gets the current user's home folder
func HomePath() string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if this returns an error? Will the visor start? If so, where will it start?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct, this could cause an odd configuration to be produced if HomePath returns an empty string.

I've now implemented a check on the config gen command to not offer the -u --user flag if HomePath returns an empty string. Similarly to how the visor determines if the -u flag should be an option based on the presence of the config or not.

if HomePath returned empty before these changes it would have been obvious from the config gen help menu as it's displayed in the flag description.

var usrconfig PkgConfig
usrconfig.Launcher.BinPath = "/Library/Application Support/Skywire/apps"
usrconfig.LocalPath = HomePath() + "/.skywire/local"
usrconfig.Hypervisor.DbPath = HomePath() + "/.skywire/users.db" //permissions errors if the process is not run as root.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are you trying to say with the comment? It seems it was copied from previous implementation for opt. Does it indeed fail if not run as root in HOME?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accidental inclusion, and the original comment issue is now basically resolved

var usrconfig PkgConfig
usrconfig.Launcher.BinPath = "C:/Program Files/Skywire/apps"
usrconfig.LocalPath = HomePath() + "/.skywire/local"
usrconfig.Hypervisor.DbPath = HomePath() + "/.skywire/users.db" //permissions errors if the process is not run as root.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question about the validity of the comment as above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accidental inclusion, and the original comment issue is now basically resolved

@mrpalide mrpalide merged commit 28ea17d into skycoin:develop Apr 18, 2022
@0pcom 0pcom deleted the x branch April 29, 2022 01:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants