Fix the file permissions and other issues in "fs_perms" tests
Hi!
Quoted 10 lines
I have checked your patch and it solves the number conversion (octal<-> decimal) issues. Thank you for that. However, the file permission issues are still valid. Please find the test execution log with this mail.
Quoted 3 lines
But then 001 is right to exec by other which should work.
010 is right to exec for group, which is the same on that line 100 is right to exec for owner, which is the same againIn this case, I partially agree with you. It is true in the case of binary files. However, We need 'read' and 'exec' for script files and these testcases deals with script files too.
Hmm I see the problem now. However as a root, I could read and run files with just an exec flag, at least here. I suppose the test works here by some saved-id magick. I'll look deeper into this.
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 7 lines
Quoted 7 lines
I have checked your patch and it solves the number conversion (octal<-> decimal) issues. Thank you for that. However, the file permission issues are still valid. Please find the test execution log with this mail.
Quoted 3 lines
But then 001 is right to exec by other which should work.
010 is right to exec for group, which is the same on that line 100 is right to exec for owner, which is the same again
Quoted 8 lines
Quoted 3 lines
In this case, I partially agree with you. It is true in the case of binary files. However, We need 'read' and 'exec' for script files and these testcases deals with script files too.
Hmm I see the problem now. However as a root, I could read and run files with just an exec flag, at least here. I suppose the test works here by some saved-id magick. I'll look deeper into this.
I think I've found the cause. The wait() funcion returns -1 if exec* hasn't succeded to run the file (and sets the status to 0). I'm not sure if this is POSIX compilant behaviour, I'll check on that later.
What flavour of glibc/kernel are you testing there, it seems that it behaves a little different than mine. Here I have glibc-2.11.
Anyway, I'll fix the test to check for return value from wait(), add the fix for octal file mode and fix the runtest files.
Thanks!
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 20 lines
Quoted 7 lines
Quoted 7 lines
I have checked your patch and it solves the number conversion (octal<-> decimal) issues. Thank you for that. However, the file permission issues are still valid. Please find the test execution log with this mail.
Quoted 3 lines
But then 001 is right to exec by other which should work.
010 is right to exec for group, which is the same on that line 100 is right to exec for owner, which is the same againQuoted 8 lines
Quoted 3 lines
In this case, I partially agree with you. It is true in the case of binary files. However, We need 'read' and 'exec' for script files and these testcases deals with script files too.
Hmm I see the problem now. However as a root, I could read and run files with just an exec flag, at least here. I suppose the test works here by some saved-id magick. I'll look deeper into this.
I think I've found the cause. The
wait()funcion returns -1 if exec* hasn't succeded to run the file (and sets the status to 0). I'm not sure if this is POSIX compilant behaviour, I'll check on that later.
Quoted 5 lines
What flavour of glibc/kernel are you testing there, it seems that it behaves a little different than mine. Here I have glibc-2.11.
Anyway, I'll fix the test to check for return value from
wait(), add the fix for octal file mode and fix the runtest files.
Grr, got myself caught. Strace behaves differently when running with root + setegid + exec, so lets start digging again.
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
In this case, I partially agree with you. It is true in the case of binary files. However, We need 'read' and 'exec' for script files and these testcases deals with script files too.
Hmm I see the problem now. However as a root, I could read and run files with just an exec flag, at least here. I suppose the test works here by some saved-id magick. I'll look deeper into this.
Quoted 5 lines
Quoted 3 lines
I think I've found the cause. The
wait()funcion returns -1 if exec* hasn't succeded to run the file (and sets the status to 0). I'm not sure if this is POSIX compilant behaviour, I'll check on that later.Check errno and see what it says.
That seems to be feature, when running under strace (to avoid users gaining root rights).
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Hmm I see the problem now. However as a root, I could read and run files with just an exec flag, at least here. I suppose the test works here by some saved-id magick. I'll look deeper into this.
I think I've found the cause. The
wait()funcion returns -1 if exec* hasn't succeded to run the file (and sets the status to 0). I'm not sure if this is POSIX compilant behaviour, I'll check on that later.
Quoted 9 lines
Quoted 5 lines
What flavour of glibc/kernel are you testing there, it seems that it behaves a little different than mine. Here I have glibc-2.11.
Anyway, I'll fix the test to check for return value from
wait(), add the fix for octal file mode and fix the runtest files.Grr, got myself caught. Strace behaves differently when running with root + setegid + exec, so lets start digging again.
Okay, seems that linux kernel (at least here) allows you to execute file if your user/group/other has at least execute rights and real uid 0.
That is the reason why these tests runs fine here.
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 3 lines
Cyril, could you please share the Linux kernel version and the some other details like name of the Linux distribution
that you are using. I think that would help.
It seems to work on various openSuSE instances (2.6.31 for example) as well as on gentoo with 2.6.37.
But unix/linux security model is full of special cases and even more fun when things like securebits and capabilities comes to play.
Anyway, I'm planning to rewrite the test to rely on setuid() and setgid() rather than on seteuid() and setegid(), which should be quite deterministic.
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
I've just commited fixes for fs_perms into git repository. Let me know if the test is working for you now.
Thanks for reporting it!
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list