-
Notifications
You must be signed in to change notification settings - Fork 426
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
ERROR : User namespace not supported, and program not running privileged. #267
Comments
Hrmm, that is very odd... Can you run it with debugging enabled( Thanks! |
Is it possible the admin has disabled the setuid in the singularity config allow setuid = no Just in case this helps, On Wed, Oct 26, 2016 at 8:41 AM, Gregory M. Kurtzer <
|
@soichih - when you get a chance to do the |
@kmuriki If it was disabled in the config we should see the line:
But now I'm double checking, and I just found something interesting... I am not doing a separate check to see if the sexec-suid is present and executable, I simply check to see if it is owned by root and is SUID. Hrmm.. I think another check is necessary, but in the mean time the strace output should be interesting. Thanks! |
@kmuriki
@bbockelm @gmkurtzer
whatever that means.. I've asked our sys admins about this and hopefully I will send you the strace later today. (update: Our sysad says "dirtyc0w stap mitigation disables ptrace") Meanwhile, here is the --debug output
|
Hrmm.. Unfortunately, no new insights... :( Yeah, for sure let us know what they say about the strace! Thanks! |
@gmkurtze I have to wait at least until next Tuesday to get the strace. strace doesn't work on karst right now because we have the dirtyCOW patch in place. The new kernel is going in next Tuesday and I will run strace again when that happens. I wonder if the issue itself is caused by this patch? |
I would think that they are unrelated, but... crossing fingers anyway! Thanks for the update! |
I think I see where this is coming from at least. We see in the --debug output that
is output. From your ls -lrt it's clear that the sexec-suid binary has the proper permissions set. If we check the code that results in this line we can see what it's doing.
Now we know that if sexec_suid_path is actually the path to the suid binary, this part will resolve properly. I'm willing to wager that sexec_suid_path is being incorrectly set because LIBEXECDIR is incorrect somehow, which in turn causes is_owner() to return(-1). LIBEXECDIR is passed from the makefile, and is substituted in at compile time not runtime. Could it be possible that your sysadmin compiled singularity first somewhere else, and then manually moved it over to the location on your /N/ file system? If this happened that would explain why the suid bit was properly set on the sexec-suid binary, as well as why the previously mentioned conditional evaluated false. The SUID bit and LIBEXECDIR preprocessor directive is set at compile time in /src/Makefile.am. I'm not sure how you could test this theory without strace however, but you can ask your sysadmin if he did something to that effect and we could maybe narrow down the issue. @gmkurtzer @soichih Let me know what you guys think. |
I think you are right. I think it was installed on a misspelled path and then later moved to the correct path.
(see "singualrity" instead of "singularity") I will ask our sysadmin to reinstall it. @gmkurtzer I was getting hit by statically compiled SYSCONFDIR earlier this morning.. I think it will be nice if the singularity binaries are relocatable.. :) (UPDATE: you probably did this for security purpose?) |
After the re-installation, I was able to start singularity. Thank you everyone for troubleshooting! |
Ohhh, this is great news! I will add in the debugging output the path that it is using to check! @bauerm97 I think some people owe you a beer including me! Shame you won't be at SC, so it will have to be a long term IOU. lol Thanks everyone! |
@soichih - just as a FYI: Non-relocatability is a basic security mechanism for Brian |
I am experiencing the same issue but the installation path should be correct, from strace
any suggestion on what could cause the problem? |
Hello, What version of Singularity are you running and can you include the Thanks! |
@raffaelepotami - I think you'll need to run |
@bbockelm Thanks Brian that would make perfect sense, I installed it as unprivileged user with ./configure --prefix=/my/path ; make;make install @gmkurtzer Gregory, I am using version 2.2 , can you confirm Brian theory about having to use here below is the log from the command
|
@bbockelm turns out you were right, make install must be done by root to make singularity work fine. Problem solved, thanks everyone R. |
Good call @bbockelm, and yes @raffaelepotami I confirm Brian's theory! lol |
I am finally testing singularity on our HTC cluster; Indiana University Karst (running on RHEL6), and I am seeing following error messages.
Our sysadmin confirmed that the singularity was cleanly installed, and I see sexec-suid installed with SUID
I've also manually confirmed that setuid works on our shared filesystem (that /N/soft is mounted on)
What else should I check?
The text was updated successfully, but these errors were encountered: