On Tuesday, April 22, 2014 15:14:33 Boaz Harrosh wrote:
> On 04/22/2014 02:37 PM, Florian Weimer wrote:
> > On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
> >> POSIX or not it just does not have any real programming mining
> >> at all.
> >
> > What do you mean with "mining" in this context?
>
>
On 04/22/2014 02:37 PM, Florian Weimer wrote:
> On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
>> POSIX or not it just does not have any real programming mining
>> at all.
>
> What do you mean with "mining" in this context?
>
Sorry I saw this mistake after I posted. I meant "meaning".
What I'm
On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
man setuid should be saying DEPRECATED, EMULATED and SIGNAL NOT SAFE
and be done with it POSIX or no POSIX who cares?
The glibc side cares, and there's also this bit: "It aims towards POSIX
and Single UNIX Specification compliance.", which should
On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
man setuid should be saying DEPRECATED, EMULATED and SIGNAL NOT SAFE
and be done with it POSIX or no POSIX who cares?
The glibc side cares, and there's also this bit: It aims towards POSIX
and Single UNIX Specification compliance., which should be
On 04/22/2014 02:37 PM, Florian Weimer wrote:
On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
POSIX or not it just does not have any real programming mining
at all.
What do you mean with mining in this context?
Sorry I saw this mistake after I posted. I meant meaning.
What I'm saying is that
On Tuesday, April 22, 2014 15:14:33 Boaz Harrosh wrote:
On 04/22/2014 02:37 PM, Florian Weimer wrote:
On 03/27/2014 02:33 PM, Boaz Harrosh wrote:
POSIX or not it just does not have any real programming mining
at all.
What do you mean with mining in this context?
Sorry I saw this
> Do we include credfd fds sitting in Unix sockets?
Ouch
> Hmm. What if we had initial_creds and creds, and initial_creds never
> changed unless explicitly requested. There wouldn't be any way to
> revert to initial_creds, but may_ptrace would check initial_creds
> *and* creds. This is a
Do we include credfd fds sitting in Unix sockets?
Ouch
Hmm. What if we had initial_creds and creds, and initial_creds never
changed unless explicitly requested. There wouldn't be any way to
revert to initial_creds, but may_ptrace would check initial_creds
*and* creds. This is a little
On Mon, Mar 31, 2014 at 1:14 PM, Trond Myklebust
wrote:
>
> On Mar 31, 2014, at 15:26, Andy Lutomirski wrote:
>
>> On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
>> wrote:
>>>
>>> On Mar 31, 2014, at 7:51, Jeff Layton wrote:
>>>
On Sun, 30 Mar 2014 09:03:29 -0400
"Theodore Ts'o"
On Mar 31, 2014, at 15:26, Andy Lutomirski wrote:
> On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
> wrote:
>>
>> On Mar 31, 2014, at 7:51, Jeff Layton wrote:
>>
>>> On Sun, 30 Mar 2014 09:03:29 -0400
>>> "Theodore Ts'o" wrote:
>>>
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff
On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
wrote:
>
> On Mar 31, 2014, at 7:51, Jeff Layton wrote:
>
>> On Sun, 30 Mar 2014 09:03:29 -0400
>> "Theodore Ts'o" wrote:
>>
>>> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had some time to think about this last night...
On Mon, Mar 31, 2014 at 11:44:59AM +0100, One Thousand Gnomes wrote:
> On Wed, 26 Mar 2014 17:23:24 -0700
> Andy Lutomirski wrote:
>
> > Hi various people who care about user-space NFS servers and/or
> > security-relevant APIs.
> >
> > I propose the following set of new syscalls:
> >
> > int
On Mon, 31 Mar 2014 14:06:01 -0400
Trond Myklebust wrote:
>
> On Mar 31, 2014, at 7:51, Jeff Layton wrote:
>
> > On Sun, 30 Mar 2014 09:03:29 -0400
> > "Theodore Ts'o" wrote:
> >
> >> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
> >>> I had some time to think about this last
On Mar 31, 2014, at 7:51, Jeff Layton wrote:
> On Sun, 30 Mar 2014 09:03:29 -0400
> "Theodore Ts'o" wrote:
>
>> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
>>> I had some time to think about this last night...
>>>
>>> While using a fd to pass around credentials is
On Mar 31, 2014 3:45 AM, "One Thousand Gnomes"
wrote:
>
> On Wed, 26 Mar 2014 17:23:24 -0700
> Andy Lutomirski wrote:
>
> > Hi various people who care about user-space NFS servers and/or
> > security-relevant APIs.
> >
> > I propose the following set of new syscalls:
> >
> > int
On Sun, 30 Mar 2014 09:03:29 -0400
"Theodore Ts'o" wrote:
> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
> > I had some time to think about this last night...
> >
> > While using a fd to pass around credentials is convenient, the danger
> > is that it's pretty opaque. You have a
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski wrote:
> Hi various people who care about user-space NFS servers and/or
> security-relevant APIs.
>
> I propose the following set of new syscalls:
>
> int credfd_create(unsigned int flags): returns a new credfd that
> corresponds to current's
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds
On Sun, 30 Mar 2014 09:03:29 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had some time to think about this last night...
While using a fd to pass around credentials is convenient, the danger
is that it's pretty opaque. You have
On Mar 31, 2014 3:45 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new
On Mar 31, 2014, at 7:51, Jeff Layton jlay...@redhat.com wrote:
On Sun, 30 Mar 2014 09:03:29 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had some time to think about this last night...
While using a fd to pass around
On Mon, 31 Mar 2014 14:06:01 -0400
Trond Myklebust trond.mykleb...@primarydata.com wrote:
On Mar 31, 2014, at 7:51, Jeff Layton jlay...@redhat.com wrote:
On Sun, 30 Mar 2014 09:03:29 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton
On Mon, Mar 31, 2014 at 11:44:59AM +0100, One Thousand Gnomes wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
trond.mykleb...@primarydata.com wrote:
On Mar 31, 2014, at 7:51, Jeff Layton jlay...@redhat.com wrote:
On Sun, 30 Mar 2014 09:03:29 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had
On Mar 31, 2014, at 15:26, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
trond.mykleb...@primarydata.com wrote:
On Mar 31, 2014, at 7:51, Jeff Layton jlay...@redhat.com wrote:
On Sun, 30 Mar 2014 09:03:29 -0400
Theodore Ts'o ty...@mit.edu
On Mon, Mar 31, 2014 at 1:14 PM, Trond Myklebust
trond.mykleb...@primarydata.com wrote:
On Mar 31, 2014, at 15:26, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 31, 2014 at 11:06 AM, Trond Myklebust
trond.mykleb...@primarydata.com wrote:
On Mar 31, 2014, at 7:51, Jeff Layton
On Sun, Mar 30, 2014 at 6:03 AM, Theodore Ts'o wrote:
> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
>> I had some time to think about this last night...
>>
>> While using a fd to pass around credentials is convenient, the danger
>> is that it's pretty opaque. You have a fd that
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
> I had some time to think about this last night...
>
> While using a fd to pass around credentials is convenient, the danger
> is that it's pretty opaque. You have a fd that you know has creds
> attached to it, but it's hard to be
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had some time to think about this last night...
While using a fd to pass around credentials is convenient, the danger
is that it's pretty opaque. You have a fd that you know has creds
attached to it, but it's hard to be certain
On Sun, Mar 30, 2014 at 6:03 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote:
I had some time to think about this last night...
While using a fd to pass around credentials is convenient, the danger
is that it's pretty opaque. You have a fd
Jeff Layton wrote:
> On Wed, 26 Mar 2014 20:25:35 -0700
> Jeff Layton wrote:
>
>> On Wed, 26 Mar 2014 20:05:16 -0700
>> Andy Lutomirski wrote:
>>
>> > On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton
>> > wrote:
>> > > On Wed, 26 Mar 2014 17:23:24 -0700
>> > > Andy Lutomirski wrote:
>> > >
>> >
Jeff Layton wrote:
On Wed, 26 Mar 2014 20:25:35 -0700
Jeff Layton jlay...@redhat.com wrote:
On Wed, 26 Mar 2014 20:05:16 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton jlay...@redhat.com
wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
On Thu, Mar 27, 2014 at 1:47 PM, Jim Lieb wrote:
> On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
>> On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb wrote:
>> > Rather than inline, I'm responding in the context of Jeremy's comments but
>> > I have to answer others as well. It is Jeremy
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
> On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb wrote:
> > Rather than inline, I'm responding in the context of Jeremy's comments but
> > I have to answer others as well. It is Jeremy after all who said my baby
> > was ugly ;).
> >
> >
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb wrote:
> Rather than inline, I'm responding in the context of Jeremy's comments but I
> have to answer others as well. It is Jeremy after all who said my baby was
> ugly ;).
>
> Jeremy is right about overloading "fd". Maybe I can call it something else
Rather than inline, I'm responding in the context of Jeremy's comments but I
have to answer others as well. It is Jeremy after all who said my baby was
ugly ;).
Jeremy is right about overloading "fd". Maybe I can call it something else
but an fd (in implementation) has merit because a creds
On Thu, Mar 27, 2014 at 11:56 AM, Jeremy Allison wrote:
> On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote:
>> On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison wrote:
>> >
>> > Amen to that :-).
>> >
>> > However, after talking with Jeff and Jim at CollabSummit,
>> > I was
On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote:
> On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison wrote:
> >
> > Amen to that :-).
> >
> > However, after talking with Jeff and Jim at CollabSummit,
> > I was 'encouraged' to make my opinions known on the list.
> >
> > To me,
On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison wrote:
>
> Amen to that :-).
>
> However, after talking with Jeff and Jim at CollabSummit,
> I was 'encouraged' to make my opinions known on the list.
>
> To me, calling the creds handle a file descriptor just
> feels wrong. IT *isn't* an fd, you
On Thu, Mar 27, 2014 at 07:01:26AM -0700, Jeff Layton wrote:
> On Thu, 27 Mar 2014 14:06:32 +0100
> Florian Weimer wrote:
>
> > On 03/27/2014 02:02 PM, Jeff Layton wrote:
> >
> > >> This interface does not address the long-term lack of POSIX
> > >> compliance in setuid and friends, which are
On Thu, Mar 27, 2014 at 8:41 AM, Florian Weimer wrote:
> On 03/27/2014 02:01 AM, Andy Lutomirski wrote:
>
>> Essentially, it's a performance problem. knfsd has override_creds,
>> and it can cache struct cred. But userspace doing the same thing
>> (i.e. impersonating a user) has to do setresuid,
On 03/27/2014 02:01 AM, Andy Lutomirski wrote:
Essentially, it's a performance problem. knfsd has override_creds,
and it can cache struct cred. But userspace doing the same thing
(i.e. impersonating a user) has to do setresuid, setresgid, and
setgroups, which kills performance, since it
On Wed, 26 Mar 2014 20:25:35 -0700
Jeff Layton wrote:
> On Wed, 26 Mar 2014 20:05:16 -0700
> Andy Lutomirski wrote:
>
> > On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton
> > wrote:
> > > On Wed, 26 Mar 2014 17:23:24 -0700
> > > Andy Lutomirski wrote:
> > >
> > >> Hi various people who care
On Thu, 27 Mar 2014 14:06:32 +0100
Florian Weimer wrote:
> On 03/27/2014 02:02 PM, Jeff Layton wrote:
>
> >> This interface does not address the long-term lack of POSIX
> >> compliance in setuid and friends, which are required to be
> >> process-global and not thread-specific (as they are on
On 03/27/2014 03:06 PM, Florian Weimer wrote:
> On 03/27/2014 02:02 PM, Jeff Layton wrote:
>
>>> This interface does not address the long-term lack of POSIX
>>> compliance in setuid and friends, which are required to be
>>> process-global and not thread-specific (as they are on the kernel
>>>
On 03/27/2014 02:02 PM, Jeff Layton wrote:
This interface does not address the long-term lack of POSIX
compliance in setuid and friends, which are required to be
process-global and not thread-specific (as they are on the kernel
side).
glibc works around this by reserving a signal and running
On Thu, 27 Mar 2014 13:46:06 +0100
Florian Weimer wrote:
> On 03/27/2014 01:23 AM, Andy Lutomirski wrote:
>
> > I propose the following set of new syscalls:
> >
> > int credfd_create(unsigned int flags): returns a new credfd that
> > corresponds to current's creds.
> >
> > int
On 03/27/2014 01:23 AM, Andy Lutomirski wrote:
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int credfd_activate(int fd, unsigned int flags): Change current's
creds to match the creds stored in fd.
On 03/27/2014 01:23 AM, Andy Lutomirski wrote:
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int credfd_activate(int fd, unsigned int flags): Change current's
creds to match the creds stored in fd.
On Thu, 27 Mar 2014 13:46:06 +0100
Florian Weimer fwei...@redhat.com wrote:
On 03/27/2014 01:23 AM, Andy Lutomirski wrote:
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int
On 03/27/2014 02:02 PM, Jeff Layton wrote:
This interface does not address the long-term lack of POSIX
compliance in setuid and friends, which are required to be
process-global and not thread-specific (as they are on the kernel
side).
glibc works around this by reserving a signal and running
On 03/27/2014 03:06 PM, Florian Weimer wrote:
On 03/27/2014 02:02 PM, Jeff Layton wrote:
This interface does not address the long-term lack of POSIX
compliance in setuid and friends, which are required to be
process-global and not thread-specific (as they are on the kernel
side).
glibc
On Thu, 27 Mar 2014 14:06:32 +0100
Florian Weimer fwei...@redhat.com wrote:
On 03/27/2014 02:02 PM, Jeff Layton wrote:
This interface does not address the long-term lack of POSIX
compliance in setuid and friends, which are required to be
process-global and not thread-specific (as they
On Wed, 26 Mar 2014 20:25:35 -0700
Jeff Layton jlay...@redhat.com wrote:
On Wed, 26 Mar 2014 20:05:16 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton jlay...@redhat.com
wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski
On 03/27/2014 02:01 AM, Andy Lutomirski wrote:
Essentially, it's a performance problem. knfsd has override_creds,
and it can cache struct cred. But userspace doing the same thing
(i.e. impersonating a user) has to do setresuid, setresgid, and
setgroups, which kills performance, since it
On Thu, Mar 27, 2014 at 8:41 AM, Florian Weimer fwei...@redhat.com wrote:
On 03/27/2014 02:01 AM, Andy Lutomirski wrote:
Essentially, it's a performance problem. knfsd has override_creds,
and it can cache struct cred. But userspace doing the same thing
(i.e. impersonating a user) has to do
On Thu, Mar 27, 2014 at 07:01:26AM -0700, Jeff Layton wrote:
On Thu, 27 Mar 2014 14:06:32 +0100
Florian Weimer fwei...@redhat.com wrote:
On 03/27/2014 02:02 PM, Jeff Layton wrote:
This interface does not address the long-term lack of POSIX
compliance in setuid and friends, which are
On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison j...@samba.org wrote:
Amen to that :-).
However, after talking with Jeff and Jim at CollabSummit,
I was 'encouraged' to make my opinions known on the list.
To me, calling the creds handle a file descriptor just
feels wrong. IT *isn't* an fd,
On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison j...@samba.org wrote:
Amen to that :-).
However, after talking with Jeff and Jim at CollabSummit,
I was 'encouraged' to make my opinions known on the list.
To me,
On Thu, Mar 27, 2014 at 11:56 AM, Jeremy Allison j...@samba.org wrote:
On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison j...@samba.org wrote:
Amen to that :-).
However, after talking with Jeff and Jim at CollabSummit,
I
Rather than inline, I'm responding in the context of Jeremy's comments but I
have to answer others as well. It is Jeremy after all who said my baby was
ugly ;).
Jeremy is right about overloading fd. Maybe I can call it something else
but an fd (in implementation) has merit because a creds
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but I
have to answer others as well. It is Jeremy after all who said my baby was
ugly ;).
Jeremy is right about overloading fd. Maybe I can call it
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but
I have to answer others as well. It is Jeremy after all who said my baby
was ugly ;).
On Thu, Mar 27, 2014 at 1:47 PM, Jim Lieb jl...@panasas.com wrote:
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but
I have to answer
On Wed, 26 Mar 2014 20:05:16 -0700
Andy Lutomirski wrote:
> On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton
> wrote:
> > On Wed, 26 Mar 2014 17:23:24 -0700
> > Andy Lutomirski wrote:
> >
> >> Hi various people who care about user-space NFS servers and/or
> >> security-relevant APIs.
> >>
> >> I
On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton wrote:
> On Wed, 26 Mar 2014 17:23:24 -0700
> Andy Lutomirski wrote:
>
>> Hi various people who care about user-space NFS servers and/or
>> security-relevant APIs.
>>
>> I propose the following set of new syscalls:
>>
>> int credfd_create(unsigned int
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski wrote:
> Hi various people who care about user-space NFS servers and/or
> security-relevant APIs.
>
> I propose the following set of new syscalls:
>
> int credfd_create(unsigned int flags): returns a new credfd that
> corresponds to current's
On Wed, Mar 26, 2014 at 5:42 PM, Serge Hallyn wrote:
> Quoting Andy Lutomirski (l...@amacapital.net):
>> Hi various people who care about user-space NFS servers and/or
>> security-relevant APIs.
>>
>> I propose the following set of new syscalls:
>>
>> int credfd_create(unsigned int flags):
Quoting Andy Lutomirski (l...@amacapital.net):
> Hi various people who care about user-space NFS servers and/or
> security-relevant APIs.
>
> I propose the following set of new syscalls:
>
> int credfd_create(unsigned int flags): returns a new credfd that
> corresponds to current's creds.
>
>
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int credfd_activate(int fd, unsigned int flags): Change current's
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int credfd_activate(int fd, unsigned int flags): Change current's
Quoting Andy Lutomirski (l...@amacapital.net):
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds to current's creds.
int
On Wed, Mar 26, 2014 at 5:42 PM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int credfd_create(unsigned int flags): returns a new credfd that
corresponds
On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton jlay...@redhat.com wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers and/or
security-relevant APIs.
I propose the following set of new syscalls:
int
On Wed, 26 Mar 2014 20:05:16 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Mar 26, 2014 at 7:48 PM, Jeff Layton jlay...@redhat.com
wrote:
On Wed, 26 Mar 2014 17:23:24 -0700
Andy Lutomirski l...@amacapital.net wrote:
Hi various people who care about user-space NFS servers
76 matches
Mail list logo
