SoC/Ideas: Difference between revisions

From SambaWiki
(moving cifs.ko witness in stale proposals)
 
Line 380: Line 380:
== Wireshark ==
== Wireshark ==
Wireshark has two SMB dissectors: "smb" for SMB1, "smb2" for SMB2 and above. It also has a DCE/RPC ([https://en.wikipedia.org/wiki/Microsoft_RPC MSRPC]) dissector that is generated from Samba IDL files.
Wireshark has two SMB dissectors: "smb" for SMB1, "smb2" for SMB2 and above. It also has a DCE/RPC ([https://en.wikipedia.org/wiki/Microsoft_RPC MSRPC]) dissector that is generated from Samba IDL files.

[[Category:GSOC]]

Latest revision as of 08:35, 17 November 2021

Applying to Samba

See our main Google Summer of Code @ Samba page for important details, plus these extended notes on applying to Samba.

Google Summer of Code: Suggested Project ideas

The following are Samba project ideas for Summer of Code. Of course you are free to come up with Samba related ideas not listed here. Please discuss your planned project by either sending an email to samba-technical@lists.samba.org or joining us on irc://irc.freenode.net/#samba-technical.

Samba

Some additional possible GSoC topics can be found in Bugzilla in the form of bugs which are marked as "Feature request": here. Questions regarding complexity and requirements should be directed to the technical mailing list.

Samba binary size reduction

Samba has grown to quite a bloated beast. This task will focus on some areas where the bloat can easily be reduced, e.g.

  • Removal of unused autogenerated librpc code
    • RPC client and server code when only serialization functions are used
    • optional struct print routines (pidl noprint?)
    • Some knowledge of perl would help here (for pidl)
  • Add new build options to compile Samba without certain functionality
    • Undesired DCE/RPC services
    • Printing support
    • Legacy SMB/CIFS support (stretch goal)

The NDR parsing Gordian knot

What we need is for someone to take the ideas in the page, and the concepts from the patch and make them a practical solution for Samba.

A particular spot where we over-link is via the ndr-table subsytem, which links to most of our (large) generated parsers for every RPC protocol we know.

Some bits of the code that link to ndr-table only want some metadata, but they end up linking to each NDR_* subsystem because the metadata is at the bottom of each parser (the ndr_*.c files).

The primary task may well end up being in Perl, or Python, or C, the challenge here will not be deep programming but lateral thinking about how to break up the dependency chains.

Making this more challenging or interesting (depending on your perspective), the RPC server is being rewritten, but for now the nexus in source3/rpc_server/rpc_ncacn_np.c and the calls to ndr_table_by_uuid() remain.

What applicants may wish to do is see if that can be re-written in such a way that does not require linking in the whole NDR parser, just to obtain the information actually used.

The broader issue

The challenge is that Samba over-links because some of the dependencies are not fine grained enough.

The fundamental challenge is likely to be a lot of cases where:

  • A depends on B
  • C depends on D

But B and C are in the same file, but B does not actually depend on C.

There are likely many other parts of Samba which link to large things that are not needed. For example, perhaps we should allow a build without printing support, or parsing of the printing protocols?

The challenge is is doing this in a way that is clean, and mostly done in the build system, not by #ifdef in the code.

Skills in determining binary dependencies, as well as the build system dependencies (to compare with) would be very helpful in this project.


Samba selftest efficiency improvement

Samba's selftest and GitLab CI pipeline has grown to quite a bloated beast. Even where we save wall-clock time by using parallel virtual machines, CPU time is spent costing the Samba Team money and using electricity more broadly.

This task will focus on some areas where the expense, bloat and duplication can easily be reduced, e.g.

  • De-duplication of duplicate test runs
  • Caching of compilation output between stages
  • Use of pipeline stages to avoid starting 20 potentially expensive jobs if a smoke-test build does not pass

The ideal candidate will do some of their own investigation to show they understand how savings could be made, rather than just sticking to this list.

  • Difficulty: medium
  • Language(s): Some knowledge of C and python would be helpful, an understanding of GitLab pipelines will help a lot
  • Possible Mentors: Andrew Bartlett

Samba AD DC as the ideal POSIX Directory

Samba is a great Active Directory Domain Controller, but it is not an ideal directory server for a large, passionate and important user base: Sites with Samba SMB servers, but also general purpose Linux servers. A smaller subset of these sites also have Linux desktops. These sites may also have Windows servers, but they like the Windows desktops, are not the focus.

These sites often used Samba + OpenLDAP, and are finding the move to Samba's AD DC a bit difficult, because schema extension is hard, some things are not done automatically (like uidNumber allocation), and in general the focus has been around matching Windows not listening to the needs of this part of our user base.

Specific research should be done into what FreeIPA does well in targeting this user segment, and what customisations advanced users of OpenLDAP apply.

This project would be to propose a number of specific improvements, and to add both tests and an implementation of these improvements to Samba.

  • Difficulty: Hard
  • Languages(s): C, Python
  • Possible Mentors: Andrew Bartlett

GitLab CI of Samba for non-linux platforms (FreeBSD in particular)

Samba uses GitLab CI to improve the quality of our patches. Efforts are currently underway to extend the docker container used from just Ubuntu 14.04 to later versions and other distributions.

However, we occasionally have issues ensuring Samba still builds and operates on FreeBSD and other non-linux platforms.

The idea would be to have a docker image and .gitlab-ci.yml code to support it that runs FreeBSD and then builds and runs Samba's testsuite inside that FreeBSD nested VM, while still outputting the results to the normal gitlab-ci.

This differs from just running GitLab CI runners on FreeBSD as we need auto-scale, destroy the host and guest at the end of the test and run on Linux docker (such as the free GitLab,com CI runners).

As a stretch goal, being able to run some tests against a specific linux kernel and a raw ext4 filesystem (rather than unionfs) via qemu rather than depending on the docker host configuraiton.

  • Difficulty: Medium
  • Language(s): Python, shell, YAML
  • Possible Mentors: Andrew Bartlett

Integrate Samba AD DC deployment and management with Cockpit

A prototype at https://github.com/abbra/cockpit-app-samba-ad shows how we can integrate Samba AD deployment with Cockpit Linux management console. A goal of this task is to move forward with this prototype to produce a fully working Samba AD management tool for common operations supported by 'samba-tool' command line utility.

The prototype is only a demo what could be done. For comprehensive work following materials need to be consulted:

The project would need to investigate:

A successful project proposal would be able to present a set of use cases proposed to focus on since this is a huge area, a scope to work on, how one would expect to work on deliverables, technology and process wise.

It would be nice to see how this project would evolve after the GSoC session would end, since it is clearly a longer term work that would need to be passed over and shared with more contributors.

  • Difficulty: Medium
  • Language(s): Python, JavaScript (React), CSS, HTML
  • Possible Mentors: Alexander Bokovoy


Linux Kernel SMB Client Improvements

The Linux Kernel has a module called cifs.ko which is independent from Samba (it doesn't share code) that allows users to mount remote shares. It supports multiple dialects of SMB (1, 2, 3). The protocol dialects are now officially documented by Microsoft (See MS-SMB, MS-SMB2) so students shouldn't have to worry about reverse engineering to understand them. The Wireshark open source network sniffer&dissector is a very good learning tool as well.


Interested students should contact Steve French or the linux-cifs mailing list to discuss possible improvements to the Linux Kernel CIFS VFS client.

Add machine-readable debug & stats /proc file

  • We currently output debug and statistic information under /proc/fs/cifs/ (DebugData, Stats, ...). We need to stop outputing free format text that breaks all parsers out there everytime we add things to it. Clean up the cifsdebug.c file (it is kind of messy). Possibly generate a hierarchy of /proc files (e.g. a dir per tcp connection, subdirs for session, files for tcons) instead of dumping everything in one file.
  • Make a nice visualizer/dashboard thing to get an overview. This could be console or GUI or...
  • Language: C for the kernel stuff, Userspace can be C, C++, Python.
  • Difficulty: Low

Add additional ftrace (trace-cmd) tracepoints and better GUI

  • Add more dynamic tracepoints to cifs.ko for commonly needed user scenarios, and add GUI (and/or CLI) tool to make it easier to enable/disable cifs.ko dynamic trace points (See /sys/kernel/debug/tracing/events/cifs/ for the pseudo-files that are currently configured manually for tracing or via trace-cmd) Make a nice native/console/web UI for it.
  • Language: C (any kernel changes) and userspace C, C++ or Python
  • Difficulty: Low

Add performance analysis cli tools

  • Add more perf tools for SMB3 client (similar to iostat or nfsstat) that leverage (and possibly extend what is captured) in /proc/fs/cifs/Stats but make it easier to analyze performance of a cifs mount
  • Language: C, C++ or Python
  • Difficulty: Low

Write the One-True-Tool to unify probe/setup/configuration cifs.ko properly

  • There are too many knobs in different places at the moment: request-keys, idmap, cifscreds, /proc stuff. This goal of this project would be to write one CLI tool that would wrap everything under a common interface. It could handle getting/setting ACL as well.
  • This would be a userspace project.
  • The implementation shouldn't too hard but the student will need to learn about the existing configuration ways and usecases which can be long.
  • Language: C, C++, Python
  • Difficulty: Medium

Add support for DAC (Claims Based ACLs) to the smb3 kernel module and tools

  • Similar to what was done to extend the Apache access control model to allow richer ACL semantics,
  • SMB3's access control model was extended (at least in Windows). See e.g. Dynamic Access Control.
  • Add support to the SMB3 kernel module and user space tools (or create new ones) to allow viewing and managing claims based ACLs (DAC) from the client.
  • Difficulty: Medium
  • Language: C (kernel), C/C++/Python (user space tools)

Add support for ODX (T10) Copy Offload to the smb3 kernel module

  • Windows, and various NAS servers support ODX copy offload (e.g. NetApp),
  • to allow much faster server side copy.
  • Add support to the kernel client for this and integration with existing or new copy offload tools to make it easy to use.
  • For more information see MS-SMB2 and SMB3 offload data transfer and Offloaded data transfers and references at bottom of Server-Side_Copy.
  • Language: C
  • Difficulty: Medium/High

VFS change notification support in cifs.ko

  • The kernel provides a file/dir notification API (inotify, dnotify). The SMB protocol also provides a way to get notified of file changes. This project would be about implementing the inotify API for cifs.ko by making use of the SMB notification mechanism.
  • Difficulty: Hard
  • Language: C



Wireshark

Wireshark has two SMB dissectors: "smb" for SMB1, "smb2" for SMB2 and above. It also has a DCE/RPC (MSRPC) dissector that is generated from Samba IDL files.