From Fedora Project Wiki

Project Title : Testing SSSD using the cwrap libraries

Contact Information

About Myself

  • I am final year student currently pursuing my Bachelor's degree in Computer Science and Engineering from Amrita University, Amrita School of Engineering, Amritapuri, India.
  • I have sound knowledge of C, C++, Python, Cmocka unit testing framework. I have great passion for open source. I have been using open source software for past four years. Later I got selected in Outreach Program for Women internship(Round 7) for Fedora project Unit test SSSD.
  • Out of my interest I did some open source contribution by fixing certain bugs in various organizations. To name some: Mozilla Firefox, Launchpad.net, Gnome and Fedora. The interest and continuous involvement helped me get selected as an OPW intern in Outreach Program for Womenfor round 7 in Fedora project Unit Test SSSD.


Why do you want to work with the Fedora Project?

I found it really appealing that Fedora provides a complete desktop operating system, including productivity applications, Internet utilities, and desktop tools. Playing around with user friendly GUI was fun. Recently I have worked on fedora:Unit Test SSSD project for twelve weeks. It was a great learning experience. I found my mentor Jakub Hrozek as well as complete fedora team to be really helpful and approachable. What I really liked was: fedora team is always ready to help you irrespective of your background knowledge, whether you are at zero level or have sound knowledge, they guide you with the same enthusiasm. The internship period helped me get familiar with many ways SSSD project works as well as gave me an opportunity to get in contact with many fedora folks. I found a vibrant working environment in fedora community. I wish to continue the same and contribute more and more to the organization.

Do you have any past involvement with the Fedora project or another open source project as a contributor?

Yes, I have contributed to [1] project and some of my work can be found here [2].

Why should we choose you over other applicants?

I have sound knowledge of C, cmocka unit test framework and basic development skills (how to build a program) which is basic requirement of the project. Project "Testing SSSD using the cwrap libraries" is a fair extension of OPW project I worked for fedora. As I have already worked on many basic modules of SSSD project I have better understanding of it and I am ready to work on more intricate modules with are a part currently proposed project . Thus I believe this makes me a strong candidate for this project.

Did you participate with the past GSoC programs, if so which years, which organizations?

No.

Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?

Yes, I wish to work with Fedora-SSSD team. I like the kind of work they have. It best suits my interest and knowledge. One factor could surely be my previous participation in SSSD project. I was working on Unit testing of SSSD which focused on the core SSSD features that are enabled in most of SSSD deployments. Thus this project will be my second contribution to fedora team and I wish to work for many more as well.

Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?

My final year exam will get over near 15th of May 2014. I do not have commitments thereafter. As the internship period starts from June 19th I can devote my complete concentration to the project itself. I assure a commitment of at least 40-45 hours per week to the project.

Experience with any other FOSS projects

I started my contribution with launchpad.net where I learned how to use bazaar, creating ssh key, cloning, pushing, pulling and merging code to mail repository. Next, I worked with Mozilla Firefox organization. Resolving some of the initial bugs made me comfortable using various version control system. The process helped me to excel in various computer languages such as C++, C, Python, HTML, XML, Mallard. I had good experience in interacting with FOSS folks through IRC and mailing list. It was a good exposure for me. It has been really exciting and fun while coding, discussing and getting involved in the open source community. The feeling of being a part of organization has been my ever encouraging source.

Link to some of the contributions I made:

I am a member of AmFoss club of our college. There we encourage each other to participate in open source. We conduct seminars, lectures, coding events, trips and have our mailing list too. It is a very active and enthusiastic group.

OPW internship: Fedora-Unit Test SSSD

  • The unit testing framework focused on the core SSSD features that are enabled in most SSSD deployments.
  • The unit tests is to covered the two most important parts:
 1 retrieving user information.
 2 authenticating users.
  • This coverage would help raise confidence in SSSD, which is the central piece of modern enterprise authentication on Linux.

Links:

Abstract

The project is about testing SSSD without having either network or root access. Normally SSSD requires both -- you need to be root to run it, several client libraries must be put into well-known system paths and also there needs to be access to a server (such as an OpenLDAP instance) over a network.

But unfortunately build systems provide neither network nor root access. This GSoC project to uses the cwrap libraries to resolve the same.

The cwrap project aims to help client/server software development teams willing to gain full functional test coverage to complete the task. It makes it possible to run several instances of the full software stack on the same machine and perform locally functional testing of complex network configurations. Daemons often require privilege separation and local user and group accounts, irrespective to the hosting system. We will show how cwrap will help you and developers interested in your project to easily test your software stack. The cwrap project does not require virtualization and can be used to build environments on different operating systems.

Project Details

The project can be explained as following.

Introduction

Testing network applications correctly is hard. The biggest challenge is often to setup the environment to test a client/server application. One option is to setup several virtual machines or containers and run a full client/server interaction between several machines. But building this environment might not always be possible, as an example build systems typically have no network at all and run as a non privileged user. It is often a hard and time consuming task to setup the development environment. Reading and running the test cases is normally a good entry point to understand a project as you learn how it is set up and how you need to use the API to achieve your goal. For these reasons, it would be preferable if there was a way to run the tests locally using a non-root user, while still being able to run in an environment as close to real world as possible. Not testing code that requires elevated privileges or networking is usually not an option, because many projects have a test driven development model. This means to submit new code or to fix issues a test case is required so regression are avoided in future.

The cwrap project

cwrap is a new project but the ideas and the origin of this new project is the Samba code-base. It presents the internals of one of the most advanced Free and Open Source Software testing systems which has successfully helped Samba developers for many years to test their protocol implementations. The cwrap project aims to help client/server software development teams willing to gain full functional test coverage to complete the task. It makes it possible to run several instances of the full software stack on the same machine and perform locally functional testing of complex network configurations.

Testing client/server issues

If you want to test your server then you can run into some problems. Your server might need to open privileged ports, which requires superuser access. If you have not only one server component but need to run several instances of daemons for different tasks, then the setup becomes more complex. An example would be you want to test a SSH client with Kerberos. So you need a KDC and an SSH server. If you provide login or authentication functionality, user and group accounts on the system are required. This means each machine you run the tests on needs to have the same users. To be able to switch to a user after authentication, you have to be root in the first place. All these things make testing harder and the setup more complex.

socket_wrapper

This library makes it possible to run several instances of the full networking stack on the same machine and perform locally functional testing of complex network configurations. socket_wrapper redirects all network communication to happen over Unix sockets, supporting IPv4 and IPv6 socket and addressing emulation. This allows you to start several daemons of a server component on the same machine without any conflicts. You are able to bind privileged ports below port 1024 without root privileges.

nss_wrapper

There are projects which provide daemons needing to be able to create, modify and delete unix users. Or just switch user IDs to interact with the system on behalf of another user, e.g. a user space file server. To be able to test that, you need the privilege to modify the passwd and groups file. With nss_wrapper it is possible to define your own passwd and groups file which will be used by software to act correctly while under test. If you have a client and server under test they normally use functions to resolve network names to addresses (DNS) or vice versa. The nss_wrappers allow you to create a hosts file to setup name resolution for the addresses you use with socket_wrapper.

uid-wrapper

Some projects like a file server need privilege separation to be able to switch to the user who owns the files and do file operations on his behalf. uid_wrapper convincingly lies to the application letting it believe it is operating as root and even switching betwen uids and gids as needed. You can start any application making it believe it is running as root.

Deriverables

  • Script that would perform verification of the user that it can communicate with server even without network in an automated fashion.
  • Automate starting SSSD.
  • Enable the SSSD to be tested after being installed to a custom directory.
  • Enable SSSD to test access control for instance.

Timeline

Period Task
Estimate - 2 weeks Get familiar with the cwrap project using available documentation, tutorials and simple experiments.
Estimate - 3 weeks Set up an LDAP server, prefill the server with users and groups. Verify, that using socket_wrapper, the user can communicate with server even without network. Write a script that would perform the above in an automated fashion
Estimate - 2 weeks Using uid_wrapper, automate starting SSSD, which normally requires root privileges as a regular user.
Estimate - 4 weeks Using nss_wrapper, make it possible to test the nss_sss module without having to install the SSSD system-wide. Completing this task would enable the SSSD to be tested after being installed to a custom directory.
Estimate - 1 weeks Leverage nss_wrapper to connect to the LDAP server with a host name and provide a mocked host name for the client. This would enable us to test access control for instance. This is a stretch goal, not required to complete the project.
Have you communicated with a potential mentor? If so, who?

Yes, I have communicated with Jakub Hrozek(Jhrozek at #sssd) and am in touch with him for quite long.