Share management

Nigel Williams nigel at veritas.com
Mon Jan 14 14:36:41 GMT 2002


Right I see the LANMAN named_pipe calls in reply_trans.  I missed them
earlier, Sorry.

Re shareadd syntax.  With my current rpcclient implementation you would use

>sharesetinfo TEST_SHARE 1501 -s
ACL:NIGEL\\nigel1:ALLOWED/0/FULL,ACL:NIGEL\\nigel2:DENIED/0/WRITE...

to set security on an existing share.

The syntax of the security descriptor is that used with smbcacls which
allows multiple ACLs.  So there
is no need to perform multiple shareadds.

The client calls implemented are

NetServerDiskEnum
NetValidateName
NetShareEnum
NetShareEnumSticky
NetShareSetInfo
NetShareGetInfo
NetShareAdd
NetShareDel
NetShareDelSticky

levels 0,1,2,501,502,1004,1005,1006,1007?,1501 are all available where
suitable.

N.B. Jeremy did the server-side implementation.

I note your preferences wrt SD manipulation from the net command. They make
good sense.

I wonder if there is any need to add these RPC client calls to the net
command if we already have the RAP versions.

A simple modification to smbcacls would give us all the functionality we
require.

Thanks

nigel

-----Original Message-----
From: Steven French [mailto:sfrench at us.ibm.com]
Sent: Monday, January 14, 2002 1:05 PM
To: Nigel Williams
Cc: samba-technical at samba.org
Subject: RE: Share management


>I think I'm right in saying that Samba does not have the server-side
>implementation of the nttrans calls required for share management via RAP.
>Is that correct?
>
> Nigel

No.   Samba does in fact also have the server side of the share management
calls. Jim McDonough added the server side of ShareAdd and ShareDelete a
few months ago (ShareEnum has been there for years).    Level 502 is not
implemented (level 2 is though).

See e.g. the function api_RNetShareAdd in smbd/lanman.c


>The ACL management that I was thinking of particularly was that of the
share
>permissions themselves as opposed to the directory permissions.  With
level
>502 and 1501 it is possible to get/set these permissions.

The second part of your questions concerns adding permissions for
individual users for a share (rather than a directory or file object).   I
slightly prefer that share permissions are considered a special case of an
access control entry (a different type of ACE) rather than an attribute of
the share since I would probably want to manage the two types of Access
Control Lists (share permissions and permissions on file/directory objects)
with similar syntax.   In addition using "shareadd" syntax seems awkward
when lots of user permissions have to be added - since the number or users
or groups who are granted access to a resource can be large and often can't
practically be specified via one long command, it seems likely that using
your syntax would have to call "shareadd" repeatedly on the same resource
(even though the share has already been added).    If access control were
to be exposed via net, I would prefer that share permisisions were exposed
via something like "net accessentry add ... resource ... user1=R
type=share" rather than forcefitting it into shareadd (alternatively you
could create a new action on shares like "share grant" or "share
addpermission" but it seems wrong to repetitively readd a share simply to
add more users to the share permissions)

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at us.ibm.com





More information about the samba-technical mailing list