RFC impersonation and substitution
jra at samba.org
Fri Oct 18 23:26:47 UTC 2019
On Wed, Oct 16, 2019 at 05:47:19PM +0200, Stefan Metzmacher via samba-technical wrote:
> some of you already saw my SDC presentation:
> Now I want to start the discussion regarding our impersonation model
> We try to get more things (including path based calls) in the smb_vfs
> layer async.
> I started with tevent_wrapper based impersonation, but that got reverted
> as it got too complex, more details can be found here:
> Currently our impersonation happens per incoming SMB request.
> We change 3 things:
> A) the unix token (uid, gid, groups)
> B) the global state in order to do smb.conf substitutions like %U
> C) we change to the share root directory
> The future idea would be that we no longer do impersonation at the
> SMB layer. Instead we would explicitly pass down enough information
> through the SMB_VFS layer, that vfs modules can do impersonation
> just around the raw syscall (or in other required places).
> The module write should know where it is required!
> Userspace filesystems may do impersonation differently.
> Of course we'll provide helper functions to make it
> easy for the module writers.
> In order to catch problem C) (relying on the correct current
> working directory) Jeremy and others are working
> hard to convert our SMB_VFS layer to *at() based syscalls.
> See https://git.samba.org/?p=samba.git;a=history;f=source3/include/vfs.h
> For problems A) and B) I have the idea to pass down
> a 'const struct samba_impersonation' as explicit argument
> to each SMB_VFS call. Note I called i 'smb_vfs_impersonation'
> in my presentation, but I realized that we need the same
> for the DCEPRC servers and changed the name.
> Regarding problem B) I'm introducing a
> 'struct loadparm_substitution' that needs tobe passed explicitly
> to each lp_*(), lpcfg_*() function that needs substitutions.
> struct samba_impersonation will wrap
> struct auth_session_info as well as struct loadparm_substitution.
> We could add more later if needed.
> I started with the struct loadparm_substitution infrastructure
> and created some draft patches for struct samba_impersonation.
> Before I continue I'd like to get some feedback.
> Please have a look and tell me if you are happy with
> that approach or if we need to find a better solution.
Just want to comment to say I think this is the right
way to move forward to modernize our VFS and move to
a completely async model.
Haven't had time to review these specific patches
yet (sorry, been busy with other things) but I'll
try and do so as soon as I get some time.
More information about the samba-technical