-
Notifications
You must be signed in to change notification settings - Fork 80
use /tmp for state dir #45
Comments
I can see it is using require 'tmpdir', but not sure why is is failing. Here user is a system user, but should be able to use a tmpdir. |
okay, it is failing because another user has already created /tmp/ruby-uuid and this user cannot use it. Pathname.new(Dir.tmpdir).join(SecureRandom.hex, 'you_filename.txt') |
or at least prefix username before the temp dir |
The state file is used to ensure that UUIDs generated by multiple users are not identical. You should coordinate access to the state file per the README. |
Would this change be okay? Is there any other place I need to make this change?
|
You can set the default state file by using UUID::state_file= as described in the README. There is no need for this type of change. It is the same as setting the state_file to false. The state file exists to prevent multiple processes from generating the same UUID. If you don't want this protection you can turn it off by setting it to false as described in the README. You should leave this protection on and set up the state file with appropriate permissions so that all processes can write to it. This is described in the documentation for UUID::state_file and UUID::state_file=. Having separate state files while multiple processes are running allows for generation of identical UUIDs. You do not want this. You want to share the state file. Please configure your processes to create the state file with the appropriate permissions (perhaps 0664). |
But why is it falling back to ~/.ruby-uuid then? That is same as state file per user. My patch is only an improvement to the fallback where the process can't find the home directory in cases like using sudo -u user. Can this be tried as an additional fallback if ~/.ruby-uuid is not writable? I will try to make it writable. Thanks for the reply. |
If you cannot write to the temporary file directory at all presumably no other process can either because your operating system is misconfigured. This allows multiple processes under the same user to have guaranteed unique UUIDs. Per-process state files do not have this guarantee. |
I can write to /tmp, and /tmp/ruby-uuid gets created. But when a second user tries to write to the same file, it fails. So if we try writing to /tmp/ruby-uuid-uid, it will succeed. I just want this as an additional fallback in cases where ~/.ruby-uuid is also not writable like in my case of using sudo -u user. And it would be better to disable state file with a warning when state file can't be written, instead of failing completely. |
and Process.uid is unique per user. |
Would this be okay? It only gets triggered if ~/.ruby-uuid is not writable and it sets state_file to false if none of the options are writable.
|
A warning will never be noticed in production. This means you lose the guarantee the state file provides without knowing. Defaulting to this fail-open scenario is not appropriate in my opinion when adequate API and documentation exist to fail-open by user choice. Instead the all users should be creating the state file with a reasonable file mode (0664 or maybe 0666 on a trusted host) or you should manually disable the state file. Per-process state files are pointless as the state only needs to be tracked in-memory. They will litter the disk and never be deleted. The change that you should make is to your use of the library, not to the library itself: require 'uuid'
UUID.state_file 0664 # or 0666 if you trust all users
uuid = UUID.new
uuuid.generate Is preferred. If you are on a shared host where you cannot trust all users: require 'uuid'
UUID.state_file = File.expand_path '~/.ruby-uuid'
uuid = UUID.new
uuuid.genaerate |
when running under 'sudo -u user' as root, it tries to create state file under /root and fails.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771544
I think it should try to create state file in /tmp
The text was updated successfully, but these errors were encountered: