-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
DartVM Feature Request: setuid / setguid #14467
Comments
It would be useful if a Dart script could change its user and group ids. Is there an equivalent on Windows? cc @sgjesse. |
It would be useful to us to be able to set it; inline with the script would be nice. I don't program in windows so I'm not qualified to mention an alternative. |
Added this to the M8 milestone. |
On Windows the permissions are defined in a structural ACL object which is much more complicated than the Linux permissions. Removed this from the M8 milestone. |
Hi again After reading this again I - of cause - misunderstood your question. This is not a matter of changing the permissions, but on supporting the setuid /setgid bits on a Dart script. I assume you would like the following: Create test.dart The last command should then run the Dart script with the effective user ID/effective group ID test_user/test_group. However for this to work the permissions needs to be set on the Dart executable. Maybe the Dart executable can do some tricks to handle this. Seems that shell-scripts does not allow this on Linux (for security reasons), but e.g. perl supports it. We still need setuid/setgid/seteuid/setegid/getuid/geteuid methods in dart:io which will have no counterparts on Windows. Regarding Windows the only thing available in this area is as far as I can see "run as", see http://support.microsoft.com/kb/305780. I don't think we can use that here though. |
This comment was originally written by [email protected] Please add this ASAP. We need a way for a HTTP server to start with root permissions to listen on port 80. Then revert back the server permission to a regular user for security reasons. Thank you in advance. |
Running with root permissions sounds like a risky scenario. I would suggest looking into one of the followings:
As Soeren mentioned above, there are some security concerns with set*id and scripts.
|
This comment was originally written by [email protected] Can you please separate the discussions about two issues? (1) Provide a way to make setuid and related system calls, or possibly their high-level abstraction. (2) Allow a Dart script to be executed with the set-user-ID mode bit or the set-group-ID mode bit set. I am not sure which of the above the OP meant by “DartVM Feature Request: setuid / setguid”. Supporting (1) and supporting (2) are pretty much disjoint tasks, although they are sometimes used in combination. |
OP here. I was asking about (1) API calls or higher level abstraction. Though now we have other ways of doing this. |
Removed Area-IO label. |
Removed this from the Later milestone. |
Removed Oldschool-Milestone-Later label. |
This comment was originally written by @kaendfinger If you need it now on Unix/Mac, you can use my syscall package: https://pub.dartlang.org/packages/syscall setUserId and setGroupId is what you want. |
This comment was originally written by @kaendfinger @kasperl @kevmoo @codefu I plan on implementing setuid/getuid support. I need guidance on what a good naming scheme would be: Platform.uid with a getter and setter vs. Platform.getUid and Platform.setUid vs. Platform.userId with getter and setter Support: |
This comment was originally written by @seaneagan @kaendfinger, issue #22037 requests adding the uid/gid getters. Getters/setters definitely are my preference. It might make sense to put them at the top-level of dart:io next to And here is a high-level permissions API which would be nice to have as well: https://github.com/seaneagan/which.dart/blob/master/lib/src/has_permission.dart |
This comment was originally written by @kaendfinger I didn't consider that, I like it. I am just always cautious to add top-level variables, but it is definitely appropriate in this case. As for the permissions, I'll have to look into this next :) |
Summary says it all.
The text was updated successfully, but these errors were encountered: