LSA Privileges

[tridge at samba.org]

> Can you list them?

SeCreateTokenPrivilege
SeAssignPrimaryTokenPrivilege
SeLockMemoryPrivilege
SeIncreaseQuotaPrivilege
SeMachineAccountPrivilege
SeTcbPrivilege
SeSecurityPrivilege
SeTakeOwnershipPrivilege
SeLoadDriverPrivilege
SeSystemProfilePrivilege
SeSystemtimePrivilege
SeProfileSingleProcessPrivilege
SeIncreaseBasePriorityPrivilege
SeCreatePagefilePrivilege
SeCreatePermanentPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeShutdownPrivilege
SeDebugPrivilege
SeAuditPrivilege
SeSystemEnvironmentPrivilege
SeChangeNotifyPrivilege
SeRemoteShutdownPrivilege
SeUndockPrivilege
SeSyncAgentPrivilege
SeEnableDelegationPrivilege

btw, can anyone tell me what windows GUI interface to use to edit the
users/groups assigned to each privilege? I presume there is a standard
admin interface for doing this, I just don't know what it is.

> Also, I will probably push them into the kernel, as we need this sort of 
> thing in our filesystem :-)

well, I'm not sure you should. See below ....

> So, it would be appreciated if there was a clean interface like the VFS.

yes, obviously I want that too. I don't think you should necessarily
assume that for filesystem backends like the one that you are working
with that the calls should go into the kernel at all. The problem is
that in order to support the full range of SMB semantics you need a
*much* richer interface to the filesystem than POSIX allows. Jamming
this interface through a posix-like kernel will inevitably be very
ugly.

If the filesystem you are working with has any coherent distributed
capabilities (such as SAN filesystems tend to have) then you can
instead use a 'each node is 2 nodes' approach. The idea is that smbd
accesses the filesystem backend directly from user-space via a library
that knows how to talk to your filesystem on its own terms, while at
the same time a kernel based filesystem accesses the same file space
via a much simpler posix-like interface. This gives you the rich
interface that SMB servers need, while keeping the kernel side
simple. 

You end up with each node in your cluster (if you are clustered)
appearing as two nodes to your SAN filesystem. One of the nodes is
Samba and the other is the kernel. The two only interface via the
filesystem itself, not via any kernel calls.

Do you think this would fit with the stuff that your company is doing?

Cheers, Tridge