Skip to content

Conversation

@mrkschan
Copy link
Contributor

@mrkschan mrkschan commented Mar 12, 2019

This patch allows user to change the cache file location by passing $TMPDIR variable or one of those supported by tempfile.tempdir over SSH.

This is desiged for container environment that has $HOME being read-only and the writeable location will be tmpfs mounted somewhere, e.g. /tmp.

@komapa
Copy link

komapa commented Mar 14, 2019

Btw, what happens if you run more than one sshuttle instance with the hosts discovery option, are they going to overwrite each other? This is not a problem you are introducing but maybe you can fix it by just generating a temporary file name as well.

@mrkschan mrkschan force-pushed the host-watch-cache-location branch from 69d971f to 9165498 Compare March 15, 2019 01:08
@mrkschan
Copy link
Contributor Author

Added uid as part of the cache file path. I guess it's expected to reuse the cache file per user.

@komapa
Copy link

komapa commented Mar 15, 2019

I am sorry I did not check earlier but I think sshuttle is correctly adding uniqueness by appending the PID to the cache file: https://github.com/sshuttle/sshuttle/pull/322/files#diff-d5c2ab2c87904bc5904c8bac0eb00b32R37

I think your first version of this PR was enough. Sorry again.

Also, this PR will not work because the directory will not exist and nowhere in the code it is currently creating it.

@mrkschan
Copy link
Contributor Author

@komapa not really, it's a atomic write creating a temporary file with the pid, https://github.com/sshuttle/sshuttle/pull/322/files#diff-d5c2ab2c87904bc5904c8bac0eb00b32R44

@mrkschan mrkschan force-pushed the host-watch-cache-location branch from 9165498 to 504f5ae Compare March 15, 2019 06:51
@mrkschan mrkschan force-pushed the host-watch-cache-location branch from 504f5ae to 581c1ae Compare March 15, 2019 06:53
@mrkschan
Copy link
Contributor Author

btw, yes, i missed the directory issue, dropping that out.

@brianmay
Copy link
Member

Using a predictable filename under /tmp makes me somewhat nervous. There are a number of potential security issues with using /tmp, especially if the filename is predictable. e.g. see https://www.netmeister.org/blog/mktemp.html

@mrkschan
Copy link
Contributor Author

@brianmay true, having /tmp as default is not secure enough. What about having a CLI option to let user select a location to hold the cache, e.g. /dev/null. This could prevent having stale cache entries being used due to slight delay in processing https://github.com/sshuttle/sshuttle/blob/master/sshuttle/hostwatch.py#L275-L277.

@brianmay
Copy link
Member

Yes, a option would probably be a good idea.

skuhl added a commit to skuhl/sshuttle that referenced this pull request Jun 2, 2021
If an exception occurs in hostwatch, sshuttle exits. Problems
read/writing the ~/.sshuttle.hosts cache file on the remote machine
would therefore cause sshuttle to exit. With this patch, we simply
continue running without writing/reading the cache file in the remote
home directory. This serves as an alternate fix for
pull request sshuttle#322 which proposed storing the cache file elsewhere.

A list of included changes:

- If we can't read or write the host cache file on the server,
  continue running. Hosts can be collected through the netstat,
  /etc/hosts, etc and the information can be reconstructed each run if
  a cache file isn't available to read. We write a log() message when
  this occurs.

- Add additional types of exceptions to handle.

- Continue even if we cannot read /etc/hosts on the server.

- Update man page to mention the cache file on the remote host.

- Indicate that messages are related to remote host instead of local
  host.

- Add comments and descriptions to the code.
@brianmay brianmay force-pushed the master branch 7 times, most recently from 646c6cf to fd6b6bb Compare February 7, 2025 22:58
@brianmay
Copy link
Member

brianmay commented Feb 8, 2025

No updates in many years. Closing.

@brianmay brianmay closed this Feb 8, 2025
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.

3 participants