> 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