Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: On Thu, 6 Dec 2012 22:26:28 +0400 Pavel Shilovsky pias...@etersoft.ru wrote: Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network filesystems, itsn't not targeted for local filesystems due security problems (e.g. when a user process can deny root to delete a file). If I have my root fs on NFS then the same applies does it not. Your patches fail to describe the security semantics and what file rights I must have to apply each option. How do I track down a lock user, what tools are provided ? How do the new options interact with the security layer? I don't have a problem with the idea, but it needs a lot more clear description of how it works so the model can be checked and if need be things tweaked (eg needing write to denywrite etc) And this is where things get really ugly of course :-). For the CIFSFS client they're expecting to be able to just ship them to a Windows server, where they'll get the (insane) Windows semantics. These semantics are not what would be wanted on a local filesystem. So unless we just say these things have Windows semantics (where openers of files can lock out others under dubious circumstances) there'll be this horrible difference between (I'm assuming) the sane semantics that are defined for local filesystems and the insane ones that you get when you're connecting remotely. I don't know a good way to fix that, but I'm pretty sure you don't want the Windows semantics defined locally :-). Jeremy.
Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: On Thu, 6 Dec 2012 22:26:28 +0400 Pavel Shilovsky pias...@etersoft.ru wrote: Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network filesystems, itsn't not targeted for local filesystems due security problems (e.g. when a user process can deny root to delete a file). If I have my root fs on NFS then the same applies does it not. Your patches fail to describe the security semantics and what file rights I must have to apply each option. How do I track down a lock user, what tools are provided ? How do the new options interact with the security layer? I don't have a problem with the idea, but it needs a lot more clear description of how it works so the model can be checked and if need be things tweaked (eg needing write to denywrite etc) And this is where things get really ugly of course :-). For the CIFSFS client they're expecting to be able to just ship them to a Windows server, where they'll get the (insane) Windows semantics. These semantics are not what would be wanted on a local filesystem. So unless we just say these things have Windows semantics (where openers of files can lock out others under dubious circumstances) there'll be this horrible difference between (I'm assuming) the sane semantics that are defined for local filesystems and the insane ones that you get when you're connecting remotely. I don't know a good way to fix that, but I'm pretty sure you don't want the Windows semantics defined locally :-). You could just flags these as ignored on local filesystems of course, exact semantics defined by the remote filesystem. That's really what applications will get anyway. But it's not condusive to writing documentation on what these things do :-). Jeremy.
Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Thu, Dec 06, 2012 at 04:31:33PM -0500, Theodore Ts'o wrote: On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: And this is where things get really ugly of course :-). For the CIFSFS client they're expecting to be able to just ship them to a Windows server, where they'll get the (insane) Windows semantics. These semantics are not what would be wanted on a local filesystem. I'm confused; why would a userspace application need to be able to request this behavior? This isn't my proposal Ted, I'm just commenting on it :-). Jeremy.
Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Thu, Dec 06, 2012 at 04:37:27PM -0500, Theodore Ts'o wrote: On Thu, Dec 06, 2012 at 01:33:29PM -0800, Jeremy Allison wrote: I'm confused; why would a userspace application need to be able to request this behavior? This isn't my proposal Ted, I'm just commenting on it :-). Ah, sorry, I thought was coming from the Samba team. :-) Well it sort of is, as the people working on cifsfs are also Samba Team members, but this isn't an official Samba thing, as I can't see exactly what apps would want this either (other than Samba smbd running on top of smbd, re-exporting a cifsfs share, pointing to a Samba server, running on a... ERROR STACK OVERFLOW :-). Hmm... I see wine-devel is cc'ed; is this coming from the Wine team, wanting to do SMB paravirtualization? It would be useful if the commit description described how these flags are intended to be used Indeed :-). Jeremy.
