Re: What to do when Windows client asks you to set permissions thatyou can't?
On Wed, 19 Mar 2003, Christopher R. Hertel wrote: > On Wed, Mar 19, 2003 at 01:59:52PM -0800, Richard Sharpe wrote: > > Hi, > > > > A question I have relating to ACLs is the following: > > > > What should you do (In Samba etc) if you get an ACE in an ACL where the > > ACE contains permission bits that you do not implement? > > > > You could: > > > > 1. Deny the request, leaving the user not knowing which > > bits were good and which not. > > > > 2. Ignore the bits you don't process, leaving the user > > in a state of confusion about which bits you support > > and which you don't. That is, leaving them not > > trusting the file system. > > > > Are there any other choices (assuming that implementing all the NT bits is > > out of the question). > > We have the same problem with DOS Attributes vs. Unix Attributes. They > don't map very well. The best you can do is try to find a way to > approximate (your best guess) of the user's intention. Right, which means that you have to document these things properly. Now, let's say that you do do some level of NT ACL, should you try to do all the permission bits. Here, you no longer have the excuse that the underlying ACLs are POSIX ACLs and that is the best you can do. Now, you implement lots more of the NT ACLs semantics, say ALLOW and DENY, along with a number of the bits (READ_DATA, WRITE_DATA, WRITE_OWNER, WRITE_ACL, APPEND_DATA), won't the user get even more confused, because you have given them something that is close to NT ACLs, but not quite? Of couse, the question is, is the distinction between WRITE_DATA, WRITE_ATTRIBUTES, and WRITE_EXTENDED_ATTRIBUTES useful? All my testing under Win2K seems to indicate that you need all three of them just to write to a file, at least in some circumstances. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
RE: What to do when Windows client asks you to set permissions thatyou can't?
On Wed, 19 Mar 2003, Ken Cross wrote: > Richard: > > By all means, leave them not trusting the file system. ;-) > > Seriously, we have a similar situation, where we have almost-Windows > ACLs. It's a continuing problem. > > However, we've found it best to do whatever is appropriate to avoid > alarming the user. Typically, this means silently doing the > next-best-thing, whatever that is. > > An example is setting Read Attributes, but disabling Read Extended > Attributes. We don't implement them both, so we set them both to > whatever the last request was. Hmmm, that sounds like you have the bits in your ACLs, but do not implement the semantics associated with them? As far as I can see, Windows requires that you have WRITE_DATA, WRITE_ATTRIBUTES and WRITE_EXTENTED_ATTRIBUTES to allow you to write to a file. This seems surprising, but not unexpected given that NTFS implements file data as the unnamed $DATA attribute :-) > It ain't perfect, but it's an approximation anyhow. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: What to do when Windows client asks you to set permissions thatyou can't?
On Wed, Mar 19, 2003 at 01:59:52PM -0800, Richard Sharpe wrote: > Hi, > > A question I have relating to ACLs is the following: > > What should you do (In Samba etc) if you get an ACE in an ACL where the > ACE contains permission bits that you do not implement? > > You could: > > 1. Deny the request, leaving the user not knowing which > bits were good and which not. > > 2. Ignore the bits you don't process, leaving the user > in a state of confusion about which bits you support > and which you don't. That is, leaving them not > trusting the file system. > > Are there any other choices (assuming that implementing all the NT bits is > out of the question). We have the same problem with DOS Attributes vs. Unix Attributes. They don't map very well. The best you can do is try to find a way to approximate (your best guess) of the user's intention. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: What to do when Windows client asks you to set permissions thatyou can't?
Richard: By all means, leave them not trusting the file system. ;-) Seriously, we have a similar situation, where we have almost-Windows ACLs. It's a continuing problem. However, we've found it best to do whatever is appropriate to avoid alarming the user. Typically, this means silently doing the next-best-thing, whatever that is. An example is setting Read Attributes, but disabling Read Extended Attributes. We don't implement them both, so we set them both to whatever the last request was. It ain't perfect, but it's an approximation anyhow. Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED] > -Original Message- > From: > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > amba.org] On Behalf Of Richard Sharpe > Sent: Wednesday, March 19, 2003 5:00 PM > To: [EMAIL PROTECTED] > Subject: What to do when Windows client asks you to set > permissions that you can't? > > > Hi, > > A question I have relating to ACLs is the following: > > What should you do (In Samba etc) if you get an ACE in an ACL > where the > ACE contains permission bits that you do not implement? > > You could: > > 1. Deny the request, leaving the user not knowing which > bits were good and which not. > > 2. Ignore the bits you don't process, leaving the user > in a state of confusion about which bits you support > and which you don't. That is, leaving them not > trusting the file system. > > Are there any other choices (assuming that implementing all > the NT bits is > out of the question). > > Regards > - > Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, > sharpe[at]ethereal.com, http://www.richardsharpe.com >
