samba - Sep 2007 - Different user permissions on the same share

Hi Samba users list, I hope you can help me.

I have installed Samba on a OpenBSD machine that belongs to a network
that have a bunch of Windows 2000 and Windows XP machines.  These
Windows machines are part of a Windows Domain but not the OpenBSD
machine.

The problem is this:

On the OpenBSD machine I need to create one share that anybody can read
but only some users can write to.  Well, if the "security = share",
anybody could read or could read/write, but I can't define some users
that can write.  (I have read the documention and it seems that, by
design, the option "write list" on Samba 3.x doesn't work with
"security
= share", correct me if I'm mistaken).

The best situation possible is, because the user on the Windows machine
is already identified himself on the Domain, the Samba should see the
username that is trying to access the share and, without asking for a
password, give to him write permissions.  (remember that anyone is able
to read the files at all times!)

The second best situation is for the Samba to ask a password to that
user.  Please keep in mind that this machine should be isolated on the
network so it will not join the Windows Domain.

In conclusion:

This should be done under the same share point;  all users can read but
only some users can write, and they shouldn't supply a password.

Can any of you point me the right directions for doing this?

Any help would be very appreciated,
Marco

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Marco A. Ferra wrote, On 09-09-2007 09:12:
> I have installed Samba on a OpenBSD machine that belongs to a network
> that have a bunch of Windows 2000 and Windows XP machines.  These
> Windows machines are part of a Windows Domain but not the OpenBSD
> machine.
	Any special reason to not join the OpenBSD on the domain?
By doing this, you could use 'security = domain' instead of
'security = share' and you could use read/write lists.

> The problem is this:
> On the OpenBSD machine I need to create one share that anybody can read
> but only some users can write to.  Well, if the "security =
share",
> anybody could read or could read/write, but I can't define some users
> that can write.  (I have read the documention and it seems that, by
> design, the option "write list" on Samba 3.x doesn't work
with "security
> = share", correct me if I'm mistaken).
> 
> The best situation possible is, because the user on the Windows machine
> is already identified himself on the Domain, the Samba should see the
> username that is trying to access the share and, without asking for a
> password, give to him write permissions.  (remember that anyone is able
> to read the files at all times!)
> 
> The second best situation is for the Samba to ask a password to that
> user.  Please keep in mind that this machine should be isolated on the
> network so it will not join the Windows Domain.
	That's strange, you will benefit by joining the Domain,
anyway, if you prefer to not do so, you probably can use ACLs
or change it to 'security = user' and use ACLs.

> In conclusion:
> This should be done under the same share point;  all users can read but
> only some users can write, and they shouldn't supply a password.
> 
> Can any of you point me the right directions for doing this?
	If you have the list of your users some way accessible
(even if you recreate them by hand, but that could be a problem
with password) you can either use ACLs or Samba read/write lists.

	There is some time I last used 'security = share', if it
still uses the user connected to read/write to the disk before
get the guest account, you could use ACLs on the filesystem.


	Kind regards,
- --
Felipe Augusto van de Wiel <felipe@paranacidade.org.br>
Coordenadoria de Tecnologia da Informa??o (CTI) - SEDU/PARANACIDADE
http://www.paranacidade.org.br/           Phone: (+55 41 3350 3300)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5ScgCj65ZxU4gPQRCAj4AJ9AflohgNOsDvDVo8/7QtDgHVI/JACeJM/K
orUo/rBwaORjX68cC1bs76I=M9+s
-----END PGP SIGNATURE-----