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?
>
> Sorr
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 say
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
> 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 littl
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" w
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 Lay
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 cr
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 convenient,
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 credfd_create(uns
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 c
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 yo
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 certa
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:
>> > >
>> >
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 a
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 ;).
> >
> > Jer
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 s
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 'encoura
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, callin
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 ca
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 req
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 result
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 about
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 the
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
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 se
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 credfd_activate(in
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 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 pr
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 c
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): returns
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.
>
> in
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
c
38 matches
Mail list logo
