Hello,
I am writing a provider that uses pthreads. The main program
does not aware that the provider is using threads and it is
not multithreaded.
After initialization the program setuid to nobody, the
problem is that my threads remains in root id.
I read about discussions regarding LinuxThreads and figured
out that I need to sync the uid,gid by my-self... :(
Is there a way in user mode to know when the process is
setuid (some kind of callback)?
The best solution is to set this callback in every thread,
so that it will setuid also when the main setuided.
Of course I can spawn a threads that pools the id of the
main process... But there must be a better way to do that.
Best Regards,
Alon Bar-Lev.
David Wagner wrote:
> In article <[email protected]> you write:
>
>>I am writing a provider that uses pthreads. The main program
>>does not aware that the provider is using threads and it is
>>not multithreaded.
>>
>>After initialization the program setuid to nobody, the
>>problem is that my threads remains in root id.
>
>
> Mixing threads and setuid programs seems like a really bad idea.
> This is especially true if you have to ask about it -- which means
> that you don't know enough to write such a program safely (please
> don't take offense).
>
I know that!
And I am aware of the (Linux implementation) implications...
I don't think you read my question in deep...
I offer a provider (Shared library), and I must deal with
this edge condition where the main program setuid.
In Linux every thread is a process so only the main thread
is setuided.
I need to catch this even in my shared library and setuid my
threads as well, since Linux pthreads implementation does
not take care of this.
Since I am not writing the main program and since I cannot
force the main programmer to behave any differently, I must
handle this internally.
Do you know a way to be notified when the process setuid?
Best Regards,
Alon Bar-Lev.
On Fri, 2005-12-23 at 11:51 +0200, Alon Bar-Lev wrote:
> David Wagner wrote:
> > In article <[email protected]> you write:
> >
> >>I am writing a provider that uses pthreads. The main program
> >>does not aware that the provider is using threads and it is
> >>not multithreaded.
> >>
> >>After initialization the program setuid to nobody, the
> >>problem is that my threads remains in root id.
> >
> >
> > Mixing threads and setuid programs seems like a really bad idea.
> > This is especially true if you have to ask about it -- which means
> > that you don't know enough to write such a program safely (please
> > don't take offense).
> >
>
> I know that!
> And I am aware of the (Linux implementation) implications...
>
> I don't think you read my question in deep...
> I offer a provider (Shared library), and I must deal with
> this edge condition where the main program setuid.
>
> In Linux every thread is a process so only the main thread
> is setuided.
>
> I need to catch this even in my shared library and setuid my
> threads as well, since Linux pthreads implementation does
> not take care of this.
>
> Since I am not writing the main program and since I cannot
> force the main programmer to behave any differently, I must
> handle this internally.
>
> Do you know a way to be notified when the process setuid?
Why on earth would you use LinuxThreads rather than NPTL? LinuxThreads
is obsolete and was never remotely POSIX compliant.
Lee
On Fri, Dec 23, 2005 at 02:08:58PM -0500, Lee Revell wrote:
> Why on earth would you use LinuxThreads rather than NPTL? LinuxThreads
> is obsolete and was never remotely POSIX compliant.
You have the strangest ideas of obsolete. NPTL has only been usable
for two years. Software lifecycles can be a lot longer than that.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Fri, 2005-12-23 at 15:21 -0500, Daniel Jacobowitz wrote:
> On Fri, Dec 23, 2005 at 02:08:58PM -0500, Lee Revell wrote:
> > Why on earth would you use LinuxThreads rather than NPTL? LinuxThreads
> > is obsolete and was never remotely POSIX compliant.
>
> You have the strangest ideas of obsolete. NPTL has only been usable
> for two years. Software lifecycles can be a lot longer than that.
>
I'm not telling you to stop supporting legacy apps, I'm just saying it's
insane to start a project now and target LinuxThreads rather than NPTL
which is what it sounded like the OP was doing.
Lee
On Fri, Dec 23, 2005 at 03:36:37PM -0500, Lee Revell wrote:
> On Fri, 2005-12-23 at 15:21 -0500, Daniel Jacobowitz wrote:
> > On Fri, Dec 23, 2005 at 02:08:58PM -0500, Lee Revell wrote:
> > > Why on earth would you use LinuxThreads rather than NPTL? LinuxThreads
> > > is obsolete and was never remotely POSIX compliant.
> >
> > You have the strangest ideas of obsolete. NPTL has only been usable
> > for two years. Software lifecycles can be a lot longer than that.
> >
>
> I'm not telling you to stop supporting legacy apps, I'm just saying it's
> insane to start a project now and target LinuxThreads rather than NPTL
> which is what it sounded like the OP was doing.
Applications have to run on existing platforms and work with existing
software, as I'm sure you know. If someone anywhere in the food chain
isn't ready for NPTL, a project can easily be stuck with LT for another
few years.
--
Daniel Jacobowitz
CodeSourcery, LLC
Daniel Jacobowitz wrote:
> On Fri, Dec 23, 2005 at 03:36:37PM -0500, Lee Revell wrote:
>
>>On Fri, 2005-12-23 at 15:21 -0500, Daniel Jacobowitz wrote:
>>
>>>On Fri, Dec 23, 2005 at 02:08:58PM -0500, Lee Revell wrote:
>>>
>>>>Why on earth would you use LinuxThreads rather than NPTL? LinuxThreads
>>>>is obsolete and was never remotely POSIX compliant.
>>>
>>>You have the strangest ideas of obsolete. NPTL has only been usable
>>>for two years. Software lifecycles can be a lot longer than that.
>>>
>>
>>I'm not telling you to stop supporting legacy apps, I'm just saying it's
>>insane to start a project now and target LinuxThreads rather than NPTL
>>which is what it sounded like the OP was doing.
>
>
> Applications have to run on existing platforms and work with existing
> software, as I'm sure you know. If someone anywhere in the food chain
> isn't ready for NPTL, a project can easily be stuck with LT for another
> few years.
>
Thank you for your comments!
Unfortunately I cannot force the users to move into NPTL...
So I thought I will create some kind of a workaround...
So back to my original question... Can I be notified if the
main setuid?
My other solution is to poll the pid of the main program for
this event.
Best Regards,
Alon Bar-Lev.
David Wagner wrote:
> Sorry, I don't know how to tell. Perhaps you can document your
> library as 'not to be used with setuid/setgid programs'? It seems
> surprising that a library would create multiple threads without warning
> the programmer that such a thing could happen (behind their back).
Hello,
Not every standard plug-in interface provides this ability.
So I must use threads behind their back... And I need to
deal with this last edge condition of the setuid.
Best Regards,
Alon Bar-Lev.
On Friday 23 December 2005 20:33, Daniel Jacobowitz wrote:
> Applications have to run on existing platforms and work with existing
> software, as I'm sure you know. If someone anywhere in the food chain
> isn't ready for NPTL, a project can easily be stuck with LT for another
> few years.
Not sure about NPTL support in non-Linux-based operating systems (Solaris,
BSD, etc), but I'd be surprised if they supported LinuxThreads. Thus,
shouldn't NPTL really result in a *more* portable application?
Luke-Jr wrote:
> On Friday 23 December 2005 20:33, Daniel Jacobowitz wrote:
>
>>Applications have to run on existing platforms and work with existing
>>software, as I'm sure you know. If someone anywhere in the food chain
>>isn't ready for NPTL, a project can easily be stuck with LT for another
>>few years.
>
>
> Not sure about NPTL support in non-Linux-based operating systems (Solaris,
> BSD, etc), but I'd be surprised if they supported LinuxThreads. Thus,
> shouldn't NPTL really result in a *more* portable application?
>
Yes... This is my first recommendation...
But what if the user does not want to upgrade?
Well... I understand that I am left with the following options:
1. upgrade to NPTL
2. My implementation of querying the main in a separate thread.
3. don't use setuid
Thank you for your help,
Alon Bar-Lev.
Luke-Jr wrote:
> On Friday 23 December 2005 20:33, Daniel Jacobowitz wrote:
>
>>Applications have to run on existing platforms and work with existing
>>software, as I'm sure you know. If someone anywhere in the food chain
>>isn't ready for NPTL, a project can easily be stuck with LT for another
>>few years.
>
>
> Not sure about NPTL support in non-Linux-based operating systems (Solaris,
> BSD, etc), but I'd be surprised if they supported LinuxThreads. Thus,
> shouldn't NPTL really result in a *more* portable application?
NPTL vs. LinuxThreads is a purely Linux-specific (well, glibc-specific,
perhaps) issue, it is merely an implementation detail of the POSIX
pthreads functions which are present on other UNIX variants. A portable
application should not care which (if either) is being used.
I'm presuming that the fact that setuid calls with LinuxThreads do not
change the user ID on all threads is a violation of the POSIX pthreads
specification.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/