On Fri, Dec 14, 2012 at 01:19:18PM -0600, Steve French wrote:
> On Fri, Dec 14, 2012 at 9:30 AM, Alan Cox wrote:
> >> We can make this feature (passing O_DENY* flags received from clients
> >> to filesystem) can be turned on/off on Samba/NFS server to let this
> >> particular use case work. In
On Fri, Dec 14, 2012 at 01:19:18PM -0600, Steve French wrote:
On Fri, Dec 14, 2012 at 9:30 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
We can make this feature (passing O_DENY* flags received from clients
to filesystem) can be turned on/off on Samba/NFS server to let this
particular use
On Fri, Dec 14, 2012 at 9:30 AM, Alan Cox wrote:
>> We can make this feature (passing O_DENY* flags received from clients
>> to filesystem) can be turned on/off on Samba/NFS server to let this
>> particular use case work. In general, I think we really need to be
>> sure that nobody has a read
> We can make this feature (passing O_DENY* flags received from clients
> to filesystem) can be turned on/off on Samba/NFS server to let this
> particular use case work. In general, I think we really need to be
> sure that nobody has a read access for files that a Windows process
> opened with
2012/12/12 David Laight :
> On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
>>
>> The problem is the possibility of denial-of-service attacks here. We
>> can try to prevent them by:
>
> FWIW I already see a DoS 'attack'.
> I have some filestore shared using NFS (to Linux and
2012/12/12 David Laight da...@l8s.co.uk:
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
The problem is the possibility of denial-of-service attacks here. We
can try to prevent them by:
FWIW I already see a DoS 'attack'.
I have some filestore shared using NFS (to Linux and
We can make this feature (passing O_DENY* flags received from clients
to filesystem) can be turned on/off on Samba/NFS server to let this
particular use case work. In general, I think we really need to be
sure that nobody has a read access for files that a Windows process
opened with
On Fri, Dec 14, 2012 at 9:30 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
We can make this feature (passing O_DENY* flags received from clients
to filesystem) can be turned on/off on Samba/NFS server to let this
particular use case work. In general, I think we really need to be
sure that
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
>
> The problem is the possibility of denial-of-service attacks here. We
> can try to prevent them by:
FWIW I already see a DoS 'attack'.
I have some filestore shared using NFS (to Linux and Solaris) and
using samba (to Windows).
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
The problem is the possibility of denial-of-service attacks here. We
can try to prevent them by:
FWIW I already see a DoS 'attack'.
I have some filestore shared using NFS (to Linux and Solaris) and
using samba (to Windows).
I
On Mon, 10 Dec 2012 11:41:16 -0500
"J. Bruce Fields" wrote:
> On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
> > The problem is the possibility of denial-of-service attacks here. We
> > can try to prevent them by:
> > 1) specifying an extra security bit on the file that
On Mon, 10 Dec 2012 11:41:16 -0500
J. Bruce Fields bfie...@fieldses.org wrote:
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
The problem is the possibility of denial-of-service attacks here. We
can try to prevent them by:
1) specifying an extra security bit on the file
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
> The problem is the possibility of denial-of-service attacks here. We
> can try to prevent them by:
> 1) specifying an extra security bit on the file that indicates that
> share flags are accepted (like we have for mandatory locks
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
The problem is the possibility of denial-of-service attacks here. We
can try to prevent them by:
1) specifying an extra security bit on the file that indicates that
share flags are accepted (like we have for mandatory locks now)
org; linux-
> fsde...@vger.kernel.org; wine-de...@winehq.org; linux-
> n...@vger.kernel.org
> Subject: Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
>
> Christoph Hellwig писал 07.12.2012 20:16:
> > On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky wrote:
> >> Network
> The problem is the possibility of denial-of-service attacks here. We
> can try to prevent them by:
> 1) specifying an extra security bit on the file that indicates that
> share flags are accepted (like we have for mandatory locks now) and
> setting it for neccessary files only, or
> 2) adding
Christoph Hellwig писал 07.12.2012 20:16:
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky 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
> I suspect that WINE would have the same need
Tricky - Wine needs to enforce this behaviour solely between Wine and
the file server, Trying to muck up non emulated local behaviour would be
a bad mistake.
One way perhaps to look at this is you want some tasks to be able to *opt
in* to this
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky 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
On Fri, Dec 07, 2012 at 10:37:45AM -0500, simo wrote:
> On Fri, 2012-12-07 at 09:52 -0500, J. Bruce Fields wrote:
> > On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
> > > 2012/12/6 Pavel Shilovsky :
> > > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
> >
On Fri, 2012-12-07 at 09:52 -0500, J. Bruce Fields wrote:
> On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
> > 2012/12/6 Pavel Shilovsky :
> > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this
> > > change can benefit cifs and nfs modules. While this
On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
> 2012/12/6 Pavel Shilovsky :
> > 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
On Fri, Dec 7, 2012 at 8:29 AM, Steve French wrote:
> although I could not find the same level of detail that MS-FSA
> provides (e.g. see section 2.14.10 for the detailed
Typo It is section 2.1.4.10
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, Dec 6, 2012 at 1:57 PM, 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 wrote:
>>
>> > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this
>> > change can benefit cifs and
2012/12/6 Pavel Shilovsky :
> 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
2012/12/6 Pavel Shilovsky pias...@etersoft.ru:
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
On Thu, Dec 6, 2012 at 1:57 PM, Jeremy Allison j...@samba.org 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
On Fri, Dec 7, 2012 at 8:29 AM, Steve French smfre...@gmail.com wrote:
although I could not find the same level of detail that MS-FSA
provides (e.g. see section 2.14.10 for the detailed
Typo It is section 2.1.4.10
--
Thanks,
Steve
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
2012/12/6 Pavel Shilovsky pias...@etersoft.ru:
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
On Fri, 2012-12-07 at 09:52 -0500, J. Bruce Fields wrote:
On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
2012/12/6 Pavel Shilovsky pias...@etersoft.ru:
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this
change can benefit cifs and nfs modules.
On Fri, Dec 07, 2012 at 10:37:45AM -0500, simo wrote:
On Fri, 2012-12-07 at 09:52 -0500, J. Bruce Fields wrote:
On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
2012/12/6 Pavel Shilovsky pias...@etersoft.ru:
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky 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
I suspect that WINE would have the same need
Tricky - Wine needs to enforce this behaviour solely between Wine and
the file server, Trying to muck up non emulated local behaviour would be
a bad mistake.
One way perhaps to look at this is you want some tasks to be able to *opt
in* to this
Christoph Hellwig писал 07.12.2012 20:16:
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky 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
The problem is the possibility of denial-of-service attacks here. We
can try to prevent them by:
1) specifying an extra security bit on the file that indicates that
share flags are accepted (like we have for mandatory locks now) and
setting it for neccessary files only, or
2) adding a
; wine-de...@winehq.org; linux-
n...@vger.kernel.org
Subject: Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
Christoph Hellwig писал 07.12.2012 20:16:
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky wrote:
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags
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 :-).
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. :-)
Hmm... I see
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,
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
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 wrote:
> >
> > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this
> > > change can
On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote:
> On Thu, 6 Dec 2012 22:26:28 +0400
> Pavel Shilovsky 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
On Thu, 6 Dec 2012 22:26:28 +0400
Pavel Shilovsky 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
>
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).
Share
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).
Share
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
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
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
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
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
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. :-)
Hmm... I see
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,
52 matches
Mail list logo
