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
Re shareadd syntax. With my current rpcclient implementation you would use
>sharesetinfo TEST_SHARE 1501 -s
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
levels 0,1,2,501,502,1004,1005,1006,1007?,1501 are all available where
N.B. Jeremy did the server-side implementation.
I note your preferences wrt SD manipulation from the net command. They make
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
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?
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
>permissions themselves as opposed to the directory permissions. With
>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)
Senior Software Engineer
Linux Technology Center - IBM Austin
email: sfrench at us.ibm.com
More information about the samba-technical