Isn't there a way to use sudoers security path in the .d file to limit to certain directories instead of blanket root ?
From searching in this forum, I understand that TurboFloatServer (on Linux) requires admin priviledges at least once to gather hardware informations (https://wyday.com/forum/t/2709/turbofloat-server-privileges/ and https://wyday.com/forum/t/4275/turbofloat-server-root-access/#post-20202 )
So I was under the impression that customers would only need to run TurboFloatServer with sudo once, the first time they activate or generate the activation request.
However, TurboFloatServer is consistently denying to work as a normal user when invoked with the “-d” (daemon) option.
This is a total deal-breaker for customers with security standards.
Please update TurboFloatServer so that it does only require admin rights to scan hardware with whatever API you may need and then no longer require them when actually executing. To our knowledge, RLM, FLEXLm and others do not enforce this.
We have no plans to change that. It's a requirement for our designs. Things are different on macOS and Windows, so they can run on those platforms if they require certain system-designs.
Each system has its trade-offs.
Also, hosted TFS instances are coming soon.
So, there are multiple options available right now, and another option coming soon.
Isn't there a way to use sudoers security path in the .d file to limit to certain directories instead of blanket root ?
Bumping again… this is still causing headaches with customers. I don't understand why TurboActivate requires sudo only once, but TurboFloat requires sudo always. Our only resort is to make our own Floating server right now… Your suggestion of using Windows or macOS is not acceptable for customers who use linux only site computers with thorough security policies.
It requires admin (but not nessarily root). Just root-like powers (but you can limit them).
Yes, we disallow chroot. That is part of the design. We have no plans to change that.
Could you detail what exactly requires admin rights to run? Maybe document what necessary rights are needed ? I've never seen a server implementation requiring admin privileges. Customers are concerned by the fact that the server opens a TCP socket on well known ports, and they are absolutely right.
You can fully customize which ports are open. Read the docs for the configuration.
https://wyday.com/limelm/help/turbofloat-server/#config-bind
https://wyday.com/limelm/help/turbofloat-server/#config-https-scgi
Also, we don’t recommend it, but they can always run on a VM (it has its own problems, but those problems are similar to allowing chroot, which you want to do anyways).