Windows Mobile 6.5 Server File Sharing Permissions

Hosting a server on Windows Mobile 6.5 relied on the lightweight server components of the underlying Windows CE 5.2 kernel, allowing devices to host services such as SMB file shares, FTP, and HTTP. Because the operating system lacked desktop Windows NTFS access control lists, file sharing permissions were enforced at the service and share levels rather than the file system level, primarily managed through registry configurations, local user authentication lists, and virtual directory mappings.

Lack of Native File-System Permissions (FAT/TFAT)

Windows Mobile 6.5 devices utilized FAT, FAT32, and Transaction-Safe FAT (TFAT) file systems for internal storage and external SD cards. These file systems do not support Discretionary Access Control Lists (DACLs) or granular, per-file security descriptors. As a result, the OS could not enforce native, file-level permissions based on user identities. All security and access restrictions had to be mediated entirely by the server application or daemon hosting the files.

Share-Level Security Model

Because file-level security was absent, Windows Mobile 6.5 relied on share-level access control. When configuring an SMB or file-sharing service, permissions applied broadly across designated directories:

• Read-Only vs. Read/Write: A shared folder was assigned a global permission mask. Connecting users were restricted to either viewing and downloading contents or granted permission to modify, upload, and delete files within the entire directory tree.
• Virtual Paths: Daemons like the built-in HTTP and FTP servers used virtual directories. Each virtual path mapped a network-facing name to a local path (such as \Storage Card\Shared) and assigned permission flags (e.g., Read, Write, Execute) specific to that path.

User Authentication and Registry-Based Accounts

Windows Mobile 6.5 did not feature a local Security Accounts Manager (SAM) database or native Active Directory domain integration for incoming requests. Instead, user authentication and access controls were maintained directly in the Windows Registry:

• User Accounts: Shared credentials were created by defining usernames and encrypted or hashed passwords under specific service registry keys (for example, under HKLM\Comm\FTPD\Users\ for FTP or HKLM\Services\SMBServer\ for SMB).
• Group and User Privileges: Registry entries mapped specific users to permitted shares and associated permissions masks.
• Anonymous/Guest Access: Most server modules included a registry setting to allow or block anonymous access. If permitted, anonymous users were generally assigned a sandboxed, read-only path with all write privileges stripped at the protocol layer.

Service Execution Context

Server components on Windows Mobile 6.5 typically ran as services under the device's service manager (services.exe). At the operating system level, this process executed with elevated device privileges, granting the server software unhindered access to the device's entire physical storage. The integrity of the file sharing permissions depended completely on the server daemon's ability to authenticate requests, validate path traversals, and restrict access boundaries before executing standard file I/O operations on the device.