> On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > If you have a many-core machine, and have many threads all wanting
> > > to briefly lock a give file (udev is known to do this), you can get
> > > quite poor perfo
> On Wed, 2018-08-08 at 17:28 -0400, J. Bruce Fields wrote:
> > On Wed, Aug 08, 2018 at 04:09:12PM -0400, J. Bruce Fields wrote:
> > > On Wed, Aug 08, 2018 at 03:54:45PM -0400, J. Bruce Fields wrote:
> > > > On Wed, Aug 08, 2018 at 11:51:07AM +1000, NeilBrown wrote:
> > > > > If you have a many-cor
> On Wed, Jan 25, 2017 at 1:43 PM, Ben Hutchings
> wrote:
> > On Wed, 2017-01-25 at 13:06 -0800, Andy Lutomirski wrote:
> >> If an unprivileged program opens a setgid file for write and passes
> >> the fd to a privileged program and the privileged program writes to
> >> it, we currently fail to cl
> Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a
> directory that is setgid and owned by a different gid than current's
fsgid, you
> end up with an SGID executable that is owned by the directory's GID. This
is
> a Bad Thing (tm). Exploiting this is nontrivial because most way
> > Hmm, but does that result in examining the whole ACL for most access
> checks, at least for files where most of the accesses are by the owner, or a
> member of a specific group (with perhaps a ton of special case users added
> on the end)?
>
> I don't understand -- what does this algorithm hav
> > + * Note: functions like richacl_allowed_to_who(),
> > +richacl_group_class_allowed(),
> > + * and richacl_compute_max_masks() iterate through the entire acl in
> > +reverse
> > + * order as an optimization.
> > + *
> > + * In the standard algorithm, aces are considered in forward order.
> > +W
> First, let me say thanks for all the work! We (Primary Data) have been using
> samba with the vfs_richacl module reexporting an nfsv4.2 mount and things
> are working pretty well. You can count on us for testing, bug fixing and code
> review.
>
> Now for my question: It looks like this call to r
> On Tue, May 10, 2016 at 06:18:10AM +0200, Volker Lendecke wrote:
> > On Tue, May 10, 2016 at 12:02:33AM +0200, Andreas Gruenbacher wrote:
> > > What more can I do to finally get this merged?
> >
> > While I am not the one to comment on kernel specifics, from a pure
> > Samba user space perspectiv
Andreas Gruenbacher:
>
> Here is another update of the richacl patch queue. I would like to ask
for
> feedback so that the core and local filesystem code (patches 1-25) can be
> merged in the 4.4 merge window.
>
> Changes since the last posting (http://lwn.net/Articles/661078/):
>
> * On ext4,
More detail on this,
Basically what is going on is that a migration event has been detected in
nfs4_get_referral, but the migration recovery is not actually initiated.
We tripped over this because Ganesha intends to support referrals, but the
implementation is incomplete (not all FSALs support re
> On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher
> wrote:
> > 2015-05-29 15:15 GMT+02:00 Trond Myklebust
> :
> >> [reply reordered]
> >> So having revisited the reasons why I chose the system.nfs4_acl
> >> interface when we did NFSv4 ACLs, I'm not sure we should implement
> >> system.richacl
> -Original Message-
> From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com]
> Sent: Wednesday, May 13, 2015 2:06 PM
> To: Frank Filz
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> n...@vger.kernel.org
> Subject: Re: [
> -Original Message-
> From: Andreas Grünbacher [mailto:andreas.gruenbac...@gmail.com]
> Sent: Wednesday, May 13, 2015 1:22 PM
> To: Frank Filz
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> n...@vger.kernel.org
> Subject: Re: [
> -Original Message-
> From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs-
> ow...@vger.kernel.org] On Behalf Of Andreas Gruenbacher
> Sent: Friday, April 24, 2015 4:04 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> n...@vger.kernel.org
> Subject: [RFC
> >> >> Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one:
> >> >>
> >> >> Permission to execute a file.
> >> >>
> >> >> Servers SHOULD allow a user the ability to read the data of the
> >> >> file when only the ACE4_EXECUTE access mask bit is allowed.
>
> On Thu, Jul 10, 2014 at 12:26 AM, Frank Filz
> wrote:
> >> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust
> >> wrote:
> >> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz
> >> >
> >> wrote:
> >> >>> On Wed, Jul 9, 2014
> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust
> wrote:
> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz
> wrote:
> >>> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz
> >>>
> >>> wrote:
> >>> > From: "Frank S. Filz"
&
> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz
> wrote:
> > From: "Frank S. Filz"
> >
> > The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS.
> >
> > The ACCESS is required to verify an open for read is actually allowed
> > because RFC 3530 indicates OPEN for read only must succeed fo
> On Tue, 29 Apr 2014 07:40:08 -0400 (EDT) "Matt W. Benjamin"
> wrote:
>
> > Hi Jeff,
> >
> > Something which came up on the last Ganesha conn call is that we have
> > a pretty strong need for some ability to wait on a set of locks, and
> > perh
> On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages)
> wrote:
> >
> > There's at least two problems to solve here:
> >
> > 1) "File private locks" is _meaningless_ as a term. Elsewhere
> >
> >
> (http://thread.gmane.org/gmane.network.samba.internals/76414/focus=16
> 8
> > 5376),
> Michael Kerrisk writes:
>
> > Hello Aneesh,
> >
> > I'm currently working on a man page for name_to_handle_at() and
> > open_by_handle_at(), and I have a question relating to a point that
> > probably needs to be covered in the man page.
> >
> > Back in July 2010, in this thread:
> > http://thr
> 2014/1/17 Frank Filz :
> > This looks wonderful and will be useful to the Ganesha user space NFS
> > server also.
> >
> > I do have a couple questions.
> >
> > 1. How will this interact with the idea of private locks from the
> > patch set Jeff Layton
This looks wonderful and will be useful to the Ganesha user space NFS server
also.
I do have a couple questions.
1. How will this interact with the idea of private locks from the patch set
Jeff Layton has been pushing?
2. If a process opens multiple file descriptors with deny modes, will they
co
> [grr, gmail -- I didn't actually intend to send that.]
>
> On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski
> wrote:
> > On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz
> wrote:
> >>> process 2 requests a write lock, gets -EDEADLK, unlocks and
>
> On Tue, Jan 14, 2014 at 12:29:17PM -0800, Andy Lutomirski wrote:
> > [cc: drh, who I suspect is responsible for the most widespread
> > userspace software that uses this stuff]
> >
> > On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce Fields
> wrote:
> > > On Thu, Jan 09, 2014 at 04:58:59PM -0800, Andy
> On Tue, 10 Dec 2013 14:17:34 -0500
> Jeff Layton wrote:
>
> > FL_FILE_PVT locks are no longer tied to a particular pid, and are
> > instead inheritable by child processes. Report a l_pid of '-1' for
> > these sorts of locks since the pid is somewhat meaningless for them.
> >
> > This precedent
> This patchset is the third posting of this set. Behavior between this set
and
> the last should be more or less the same. Here is a summary of
> changes:
>
> v3:
> - more consolidation of common code between flock_to_posix_lock and
> flock_to_posix_lock64
> - better bisectability by reordering
> FL_FILP_PRIVATE locks are no longer tied to a particular PID, and are
instead
> inheritable by child processes. Report a l_pid of '-1' for these sorts of
locks
> since the pid is somewhat meaningless for them.
Hmm, I suppose in the case of a process that acquires a private lock, forks
(passing t
> http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2
> > > .html
> > >
> > > See the section entitled "First Implementation Past the Post".
> >
> > Interesting that Jeremy actually suggested the implementation should
> > have had an arbitrary lock owner as part of the flock struct
> This blog post of Jeremy's explains some of the history:
>
>
> http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2
> .html
>
> See the section entitled "First Implementation Past the Post".
Interesting that Jeremy actually suggested the implementation should have
had an arbit
> > > At LSF this year, there was a discussion about the "wishlist" for
> > > userland file servers. One of the things brought up was the goofy
> > > and problematic behavior of POSIX locks when a file is closed. Boaz
> > > started a thread on it here:
> > >
> > > http://permalink.gmane.org/gma
> > > > > > At LSF this year, there was a discussion about the "wishlist"
> > > > > > for userland file servers. One of the things brought up was
> > > > > > the goofy and problematic behavior of POSIX locks when a file is
> closed.
> > > > > > Boaz started a thread on it here:
> > > > > >
> > > >
> > > > At LSF this year, there was a discussion about the "wishlist" for
> > > > userland file servers. One of the things brought up was the goofy
> > > > and problematic behavior of POSIX locks when a file is closed.
> > > > Boaz started a thread on it here:
> > > >
> > > > http://permalink.g
> > At LSF this year, there was a discussion about the "wishlist" for
> > userland file servers. One of the things brought up was the goofy and
> > problematic behavior of POSIX locks when a file is closed. Boaz
> > started a thread on it here:
> >
> > http://permalink.gmane.org/gmane.linux.fil
linux-nfs-ow...@vger.kernel.org wrote on 04/10/2013 06:24:39 AM:
> 2013/4/10 Jeff Layton :
> > On Tue, 9 Apr 2013 16:40:21 +0400
> > Pavel Shilovsky wrote:
> >
> >> This patch adds 3 flags:
> >> 1) O_DENYREAD that doesn't permit read access,
> >> 2) O_DENYWRITE that doesn't permit write access,
35 matches
Mail list logo
