request to remove security=share

simo idra at
Sun Mar 12 19:21:17 GMT 2006

On Sun, 2006-03-12 at 13:04 -0600, Christopher R. Hertel wrote:
> Volker Lendecke wrote:
> > On Sun, Mar 12, 2006 at 11:50:19AM -0600, Christopher R. Hertel wrote:
> > 
> >>One thing I think you'll want to do is an implicit "force user" to force
> >>the read-only user to "become" the read/write user once authentication is
> >>complete. 
> > 
> > 
> > That's what I meant that the user would be treated as if
> > coming from the session setup.
> Um...  I think we're close here but I think I may be talking about something
> different.
> I think what you are talking about is this:  When the connection happens,
> you'd first use the "share write user" as the username in the session
> setup.  If that failed, then you'd use the "share read user" and try 
> authentication again.
> What I'm adding is this:  If the "share write user" fails but the "share
> read user" succeeds, then you'd want to force actual user ID to be same as
> the user defined in the "share write user" field.  That way, there are no
> unexpected results caused by having two different actual user IDs
> accessing the share.

Why don't just add a read only password and a read write password ?
We already have the username option, we just need to change it to be
the name of the user we are going to access the share with in the
security=share case.

For these shares the read only flag will be triggered based on the
password used. Passwords will be stored in secrets.tdb indexed by

This is an easy setup and follows what win9x has always done so that it
makes more understandable to admins.


Simo Sorce
Samba Team GPL Compliance Officer
email: idra at

More information about the samba-technical mailing list