Pushing Samba functions into the kernel

Richard Sharpe rsharpe at richardsharpe.com
Thu Feb 13 23:04:17 GMT 2003


On Thu, 13 Feb 2003 jra at dp.samba.org wrote:

> Ok, my feelings on "Samba in the kernel" are the following.
> 
> 1). We need to be able to de-multiplex incoming SMB's at the kernel
> level to get over the W2K Terminal Server problem.

OK, I am not familiar with this problem. Can you say more please.
 
> 2). A utf8 case-insensitive filesystem (massive performance win).

Yes. I agree. We are looking at this issue.

> 3). Implement SMBreadX/SMBwriteX in the kernel once a channel has
> been set up.

Right. I think the open code would be best left to Userland, at least 
initially. However, some FIDs we would not want the kernel to handle, I 
suspect, eg RPC FIDs. So we need a mechanism to communicate things between 
Samba and the kernel.

> 4). Allow NT SD's stored in EA's to be interpreted by security
> code living in the kernel for open decisions.

Indeed. We already have a mechanism in our File System that does this. It 
is not what I really want, because it should be in the kernel, but for the 
moment it is in the file system and works. 

With the privilege code coming into Samba, we also need privileges in the 
kernel as well, and in Linux, you might be able to map this onto 
capabilities, or perhaps do something orthogonal to capabilities with LSM.

An additional area of concern here equivalence between NFS users and CIFS 
users. It seems (at least to me) that you can use one of two approaches:

1. Name equivalence, where you look up the name associated with a UID/GID 
and then check if an in incoming SID has the same name.

2. Administrative equivalence. Where you provide somewhere in a database 
the equivalence between SIDs and UIDs/GIDs. 

However, these become issues that Samba does not have to worry about these 
issues if they are done in the kernel.

> Everything else (IMHO) is better done in user space.

I only want to move what makes sense ...

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com



More information about the samba-technical mailing list