2009/184 SMB/CIFS Share Exec Properties

[Darren J Moffat]

Jordan Brown wrote:
>     In order to configure properties using sharectl(1M), a user must
>     be the superuser or assume an equivalent role to obtain the
>     solaris.smf.value.smb and solaris.smf.manage.smb RBAC
>     authorizations, or use the SMB Management RBAC profile, which
>     is part of the File System Management profile.

This case makes that authorisation equivalent to handing out the list of 
privileges below.  I'm not sure that is a safe thing to do.

I need some more time to thing about this and see if there is a safer 
way to achieve this.  I have some ideas (that won't be difficult to 
implement) I just need to think through them a bit more first.

>     Additional privileges are required to allow the smbd process to
>     fork a child process and execute the commands.  The privileges
>     will be enabled in the effective set and inheritable set when
>     needed for command execution.  Otherwise, they will be disabled.
> 
>     The following privileges are enabled for the exec'd process:
>     PRIV_FILE_CHOWN, PRIV_FILE_CHOWN_SELF, PRIV_FILE_DAC_EXECUTE,
>     PRIV_FILE_DAC_READ, PRIV_FILE_DAC_SEARCH, PRIV_FILE_DAC_WRITE,
>     PRIV_FILE_LINK_ANY, PRIV_FILE_OWNER, PRIV_FILE_SETID,
>     PRIV_PROC_EXEC, PRIV_PROC_FORK, PRIV_PROC_INFO, PRIV_PROC_OWNER,
>     PRIV_PROC_SESSION, PRIV_PROC_SETID, PRIV_SYS_CONFIG,
>     PRIV_SYS_LINKDIR, and PRIV_SYS_MOUNT.

Where did this list of privileges come from (other than those in the 
basic set)?  Why this list and in particular why the very powerful 
sys_config ?

Is it just because that is what smbd is running with ?  I want the case 
to give the reason why this set of privileges rather than some other set 
is the correct and useful set.

-- 
Darren J Moffat