Project 17: RPC with Authentication

Extend the RPC calculator with authentication.

Quick Reference

Attribute Value
Difficulty Level 3 (Advanced)
Time Estimate 1 Week
Main Programming Language C (Alternatives: )
Alternative Programming Languages N/A
Coolness Level Level 3 (Genuinely Clever)
Business Potential Level 3 (Service & Support)
Prerequisites C programming, basic IPC familiarity, Linux tools (strace/ipcs)
Key Topics AUTH_SYS, AUTH_DH, authorization

1. Learning Objectives

By completing this project, you will:

  1. Build a working IPC-based system aligned with Stevens Vol. 2 concepts.
  2. Implement robust lifecycle management for IPC objects.
  3. Handle errors and edge cases deterministically.
  4. Document and justify design trade-offs.
  5. Benchmark or validate correctness under load.

2. All Theory Needed (Per-Concept Breakdown)

RPC Authentication: AUTH_SYS and AUTH_DH

Fundamentals

Sun RPC supports pluggable authentication mechanisms called “auth flavors.” AUTH_SYS (also called AUTH_UNIX) sends UID/GID credentials in the clear, relying on trusted networks. AUTH_DH (Diffie-Hellman) provides stronger authentication by using cryptographic handshakes. Most modern systems replace these with RPCSEC_GSS, but understanding AUTH_SYS and AUTH_DH explains the historical security model of RPC.

Deep Dive into the Concept

AUTH_SYS is simple: the client includes its UID, GID, and group list in each RPC call. The server can accept or reject based on these values. The problem is that the credentials are not protected; any attacker who can send packets can forge them. AUTH_SYS is therefore only safe on trusted, local networks. Despite this, it is still used in many legacy systems.

AUTH_DH uses public-key cryptography to establish a shared secret. The client and server exchange credentials and use a time-based verifier to prevent replay attacks. This is more secure but also more complex and less widely supported. Implementations vary by platform; in some environments, AUTH_DH is disabled or unavailable.

Security in RPC is not just about authentication; it is also about authorization and audit. Even with AUTH_SYS, you should log UID/GID, restrict sensitive operations, and consider network segmentation. In a modern environment, you would likely use RPCSEC_GSS or replace Sun RPC with TLS-secured protocols, but the learning value here is in understanding the trade-offs of early RPC security designs.

How this fits on projects

Authentication extends the RPC calculator into a realistic service. It also introduces security concepts that will matter in distributed systems work.

Definitions & key terms

  • AUTH_SYS -> UID/GID-based authentication.
  • AUTH_DH -> Diffie-Hellman authentication for RPC.
  • Replay attack -> Reusing captured credentials.

Mental model diagram (ASCII)

Client credentials -> RPC call -> Server policy check

RPC authentication flow

How it works (step-by-step, with invariants and failure modes)

  1. Client selects auth flavor.
  2. Credentials are attached to RPC calls.
  3. Server validates credentials and authorizes.
  4. Server rejects or accepts the request.

Failure modes: mismatched auth flavor, forged AUTH_SYS credentials, replay attacks.

Minimal concrete example

CLIENT *cl = clnt_create(host, PROG, VERS, "tcp");
cl->cl_auth = authsys_create_default();


**Common misconceptions**

- "AUTH_SYS is secure." -> It is not on untrusted networks.
- "Authentication equals authorization." -> You still need policy checks.
- "AUTH_DH is always available." -> Support varies by platform.

**Check-your-understanding questions**

1. Why is AUTH_SYS insecure on untrusted networks?
2. What problem does AUTH_DH solve?
3. How do you handle auth failures distinctly from network failures?

**Check-your-understanding answers**

1. Credentials are sent in clear and can be forged.
2. It provides cryptographic verification and replay protection.
3. Use explicit error codes and log auth failures separately.

**Real-world applications**

- NFS AUTH_SYS environments in trusted networks.

**Where you’ll apply it**

- In this project: §3.2 Functional Requirements, §7 Common Pitfalls.
- Also used in: [P18-rpc-kvstore.md](P18-rpc-kvstore.md).

**References**

- Stevens, "UNP Vol 2" Ch. 17.
- `man 3 authsys_create`.

**Key insights**

- Authentication is only as strong as the network you trust.

**Summary**

RPC authentication exposes the limits of early security models and shows why modern secure RPC frameworks exist.

**Homework/Exercises to practice the concept**

1. Implement AUTH_SYS and log UID/GID on the server.
2. Simulate a forged UID and observe server policy.
3. Explore RPCSEC_GSS documentation for modern alternatives.

**Solutions to the homework/exercises**

1. Use `authsys_create_default()` and print credentials.
2. Override client UID and confirm server rejection.
3. Read platform docs and summarize supported mechanisms.


---

## 3. Project Specification

### 3.1 What You Will Build

Extend the RPC calculator with authentication.

### 3.2 Functional Requirements

1. **Requirement 1**: Support AUTH_SYS at minimum
2. **Requirement 2**: Reject unauthorized requests
3. **Requirement 3**: Log credentials

### 3.3 Non-Functional Requirements

- **Performance**: Must handle at least 10,000 messages/operations without failure.
- **Reliability**: IPC objects are cleaned up on shutdown or crash detection.
- **Usability**: CLI output is readable with clear error codes.

### 3.4 Example Usage / Output

```text
./calc_client_auth localhost add 7 9 --auth sys


### 3.5 Data Formats / Schemas / Protocols

Auth metadata in RPC headers.

### 3.6 Edge Cases

- Auth mismatch
- Spoofed credentials
- Replay

### 3.7 Real World Outcome

You will have a working IPC subsystem that can be run, traced, and tested in a reproducible way.

#### 3.7.1 How to Run (Copy/Paste)

```bash
make
./run_demo.sh


#### 3.7.2 Golden Path Demo (Deterministic)

```bash
./run_demo.sh --mode=golden


Expected output includes deterministic counts and a final success line:

```text
OK: golden scenario completed


#### 3.7.3 Failure Demo (Deterministic)

```bash
./run_demo.sh --mode=failure


Expected output:

```text
ERROR: invalid input or unavailable IPC resource
exit=2


---

## 4. Solution Architecture

### 4.1 High-Level Design


Client/Producer -> IPC Layer -> Server/Consumer

Client to IPC layer to server flow

4.2 Key Components

Component Responsibility Key Decisions
IPC Setup Create/open IPC objects POSIX vs System V choices
Worker Loop Send/receive messages Blocking vs non-blocking
Cleanup Unlink/remove IPC objects Crash safety

4.3 Data Structures (No Full Code)

struct message {
  int id;
  int len;
  char payload[256];
};


### 4.4 Algorithm Overview

**Key Algorithm: IPC Request/Response**
1. Initialize IPC resources.
2. Client sends request.
3. Server processes and responds.
4. Cleanup on exit.

**Complexity Analysis:**
- Time: O(n) in number of messages.
- Space: O(1) per message plus IPC buffer.

---

## 5. Implementation Guide

### 5.1 Development Environment Setup

```bash
sudo apt-get install build-essential


### 5.2 Project Structure


project-root/
├── src/
├── include/
├── tests/
├── Makefile
└── README.md

Project root directory layout

5.3 The Core Question You’re Answering

“How do you add identity to RPC calls?”

5.4 Concepts You Must Understand First

  • IPC object lifecycle (create/open/unlink)
  • Blocking vs non-blocking operations
  • Error handling with errno

5.5 Questions to Guide Your Design

  1. What invariants guarantee correctness in this IPC flow?
  2. How will you prevent resource leaks across crashes?
  3. How will you make the system observable for debugging?

5.6 Thinking Exercise

Before coding, sketch the IPC lifecycle and identify where deadlock could occur.

5.7 The Interview Questions They’ll Ask

  1. Why choose this IPC mechanism over alternatives?
  2. What are the lifecycle pitfalls?
  3. How do you test IPC code reliably?

5.8 Hints in Layers

Hint 1: Start with a single producer and consumer.

Hint 2: Add logging around every IPC call.

Hint 3: Use strace or ipcs to verify resources.

5.9 Books That Will Help

Topic Book Chapter
IPC fundamentals Stevens, UNP Vol 2 Relevant chapters
System calls APUE Ch. 15

5.10 Implementation Phases

Phase 1: Foundation (2-4 hours)

Goals:

  • Create IPC objects.
  • Implement a minimal send/receive loop.

Tasks:

  1. Initialize IPC resources.
  2. Implement basic client and server.

Checkpoint: Single request/response works.

Phase 2: Core Functionality (4-8 hours)

Goals:

  • Add error handling and cleanup.
  • Support multiple clients or concurrent operations.

Tasks:

  1. Add structured message format.
  2. Implement cleanup on shutdown.

Checkpoint: System runs under load without leaks.

Phase 3: Polish & Edge Cases (2-4 hours)

Goals:

  • Add deterministic tests.
  • Document behaviors.

Tasks:

  1. Add golden and failure scenarios.
  2. Document limitations.

Checkpoint: Tests pass, behavior documented.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Blocking mode blocking vs non-blocking blocking Simpler for first version
Cleanup manual vs automated explicit cleanup Avoid stale IPC objects

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Validate helpers message encode/decode
Integration Tests IPC flow client-server round trip
Edge Case Tests Failure modes missing queue, full buffer

6.2 Critical Test Cases

  1. Single client request/response works.
  2. Multiple requests do not corrupt state.
  3. Failure case returns exit code 2.

6.3 Test Data

Input: “hello” Expected: “hello”

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Not cleaning IPC objects Next run fails Add cleanup on exit
Blocking forever Program hangs Add timeouts or non-blocking mode
Incorrect message framing Corrupted data Add length prefix and validate

7.2 Debugging Strategies

  • Use strace -f to see IPC syscalls.
  • Use ipcs or /dev/mqueue to inspect objects.

7.3 Performance Traps

  • Small queue sizes cause frequent blocking.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add verbose logging.
  • Add a CLI flag to toggle non-blocking mode.

8.2 Intermediate Extensions

  • Add request timeouts.
  • Add a metrics report.

8.3 Advanced Extensions

  • Implement load testing with multiple clients.
  • Add crash recovery logic.

9. Real-World Connections

9.1 Industry Applications

  • IPC services in local daemons.
  • Message-based coordination in legacy systems.
  • nfs-utils - Uses RPC and IPC extensively.
  • systemd - Uses multiple IPC mechanisms.

9.3 Interview Relevance

  • Demonstrates system call knowledge and concurrency reasoning.

10. Resources

10.1 Essential Reading

  • Stevens, “UNP Vol 2”.
  • Kerrisk, “The Linux Programming Interface”.

10.2 Video Resources

  • Unix IPC lectures from OS courses.

10.3 Tools & Documentation

  • man 7 ipc, man 2 for each syscall.

11. Self-Assessment Checklist

11.1 Understanding

  • I can describe IPC object lifecycle.
  • I can explain blocking vs non-blocking behavior.
  • I can reason about failure modes.

11.2 Implementation

  • All functional requirements are met.
  • Tests pass.
  • IPC objects are cleaned up.

11.3 Growth

  • I can explain design trade-offs.
  • I can explain this project in an interview.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Basic IPC flow works with correct cleanup.
  • Error handling returns deterministic exit codes.

Full Completion:

  • Includes tests and deterministic demos.
  • Documents trade-offs and limitations.

Excellence (Going Above & Beyond):

  • Adds performance benchmarking and crash recovery.