[Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Frederik Bayart]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Hallo,

We are switching from linux 2.6.30.8 with xenomai 2.4.10  to linux 2.6.38.8
with xenomai 2.6.0 (stable release) on debian lenny.

In our daemon (with real pid root), we are setting effective pid and gid to
1000 and are calling popen to execute a shell command.
The popen succeeds, but when I try to read the output with fgets, I get the
error :

Xenomai: binding failed: Operation not permitted.

I verified that the effective user for both commands is the same.

This was working on xenomai 2.4.10
I added the user with pid 1000 already to the xenomai group but this
doesn't work.

Does anyone know what the problem could be ?


Frederik

[-- Attachment #2: Type: text/html, Size: 711 bytes --]

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 04/25/2012 12:28 PM, Frederik Bayart wrote:
> Hallo,
> 
> We are switching from linux 2.6.30.8 with xenomai 2.4.10  to linux 2.6.38.8
> with xenomai 2.6.0 (stable release) on debian lenny.
> 
> In our daemon (with real pid root), we are setting effective pid and gid to
> 1000 and are calling popen to execute a shell command.
> The popen succeeds, but when I try to read the output with fgets, I get the
> error :
> 
> Xenomai: binding failed: Operation not permitted.
> 
> I verified that the effective user for both commands is the same.
> 
> This was working on xenomai 2.4.10
> I added the user with pid 1000 already to the xenomai group but this
> doesn't work.
> 
> Does anyone know what the problem could be ?

Quite frankly, the description is a bit vague. For instance, the
"binding failed: operation not permitted" message should happens as a
result of starting a program, or as a result of popen, not when calling
fgets. Anyway, please try and reduce the bug to a simple and minimal
test case which still causes the bug, and post the code here. A piece of
code is worth a thousand words, and this exercise may help you identify
which piece of the puzzle causes the bug.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 04/25/2012 04:00 PM, Frederik Bayart wrote:
> Migration to squeeze is the next step planned.
> In attachment a small test program to reproduce the problem and a makefile.
> The program is running as root but we want e.g. the command executed
> by the popen command running as user 'triphase'
> 
> if you run the program and press CTRL-C, you get Xenomai: binding
> failed on 2.6.0 and output (of part of the output) from 'ls' on
> 2.4.10.

I am afraid you will have to add the triphase user to the xenomai group
and pass the xeno_nucleus.xenomai_gid option to the kernel. Or else
rewrite the vfork + exec yourself dropping root privileges after the fork.

The reason is that the native api assumes that if you fork in a xenomai
program, chances are you will want to use the native api in the child
program.
-- 
					    Gilles.

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 04/25/2012 12:28 PM, Frederik Bayart wrote:
> Hallo,
> 
> We are switching from linux 2.6.30.8 with xenomai 2.4.10  to linux 2.6.38.8
> with xenomai 2.6.0 (stable release) on debian lenny.

If you are concerned with security (which seems to be the case since you
want to avoid running real-time programs as root):
- you should note that debian lenny is no longer maintained for security
update (since february actually), so, an upgrade to squeeze is
recommended. Chances are that it is possible to become root when running
as an ordinary user on a lenny system without too much trouble.
- it is entirely possible that it is possible to become root abusing
xenomai interfaces, xenomai interfaces are not implemented with security
in mind.

> 
> In our daemon (with real pid root), we are setting effective pid and gid to
> 1000 and are calling popen to execute a shell command.
> The popen succeeds, but when I try to read the output with fgets, I get the
> error :
> 
> Xenomai: binding failed: Operation not permitted.
> 
> I verified that the effective user for both commands is the same.
> 
> This was working on xenomai 2.4.10
> I added the user with pid 1000 already to the xenomai group but this
> doesn't work.

That is not enough, you should also do what is said here:
http://www.xenomai.org/index.php/Non-root_RT

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Frederik Bayart]

now with mailing list in cc

Hallo Gilles,

 by adding my user to group xenomai and configuring the
 xeno_nucleus.xenomai_gid parameter on the command line, I was able to
 run my binary as non-root, so my problem is solved.

 However, I noticed that if I start my binary as root, and using
 seteuid and setegid to non-root as in de example still fails. I don't
 know whether this is normal or a bug.

 Frederik
>
> On 29 April 2012 17:56, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 04/25/2012 12:28 PM, Frederik Bayart wrote:
>>> Hallo,
>>>
>>> We are switching from linux 2.6.30.8 with xenomai 2.4.10  to linux 2.6.38.8
>>> with xenomai 2.6.0 (stable release) on debian lenny.
>>
>> If you are concerned with security (which seems to be the case since you
>> want to avoid running real-time programs as root):
>> - you should note that debian lenny is no longer maintained for security
>> update (since february actually), so, an upgrade to squeeze is
>> recommended. Chances are that it is possible to become root when running
>> as an ordinary user on a lenny system without too much trouble.
>> - it is entirely possible that it is possible to become root abusing
>> xenomai interfaces, xenomai interfaces are not implemented with security
>> in mind.
>>
>>>
>>> In our daemon (with real pid root), we are setting effective pid and gid to
>>> 1000 and are calling popen to execute a shell command.
>>> The popen succeeds, but when I try to read the output with fgets, I get the
>>> error :
>>>
>>> Xenomai: binding failed: Operation not permitted.
>>>
>>> I verified that the effective user for both commands is the same.
>>>
>>> This was working on xenomai 2.4.10
>>> I added the user with pid 1000 already to the xenomai group but this
>>> doesn't work.
>>
>> That is not enough, you should also do what is said here:
>> http://www.xenomai.org/index.php/Non-root_RT
>>
>> --
>>                                                                Gilles.
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
>
>
> --
> Frederik Bayart | Senior software engineer
> Triphase NV | Research Park Zone 1719 | Romeinse straat 18 | B-3001 Heverlee
> T  +32 2 669 06 05 | E frederik.bayart@domain.hid | W www.triphase.com



-- 
Frederik Bayart | Senior software engineer
Triphase NV | Research Park Zone 1719 | Romeinse straat 18 | B-3001 Heverlee
T  +32 2 669 06 05 | E frederik.bayart@domain.hid | W www.triphase.com

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Gilles Chanteperdrix]

On 05/11/2012 05:02 PM, Frederik Bayart wrote:
> now with mailing list in cc
> 
> Hallo Gilles,
> 
>  by adding my user to group xenomai and configuring the
>  xeno_nucleus.xenomai_gid parameter on the command line, I was able to
>  run my binary as non-root, so my problem is solved.
> 
>  However, I noticed that if I start my binary as root, and using
>  seteuid and setegid to non-root as in de example still fails. I don't
>  know whether this is normal or a bug.

It is normal. For your case to run, the fork itself must be run a root.
So, you should call again seteuid/setegid before vfork, then drop again
the rights before exec (if you do not want the exec to be run as root).

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

Jan Kiszka wrote:
> s.a. wrote:
>> Hi,
>>
>> In my mind , one or more rt process manages everything critical, need
>> root access for resources reasons , other processes are things like gui
>> to interact with realtime world, including  X11 applications (I know , I
>> will hurt some people, but this is the truth : X11 !) .....
>>
> 
> My point is: what do you gain by separating the RT core from the logging
> or gui application? Not much as long as the interface is not robust.
> This means that your uncritical part must not be able to interfere with
> the critical one, e.g. by acquiring some common lock or messing up a
> shared memory which is used blindly by the RT code. If your application
> design can guarantee this, ok.
> 
> But then note that Xenomai heaps are unsuited for being shared with not
> fully trusted parties: management structures reside next to the data,
> write permission is always acquired (and is required for
> allocation/release operations), access control beyond go/no-go is not
> supported. Better use "standard" (Linux) shared memory for this: Invoke
> shm_open("myshm", ...), adapt the access rights of the newly created
> /dev/shm/myshm, and let the unprivileged process attach to it.
> 

I haven't looked at this module so far in details, but from the first
quick glance I just took it looks like a simple way to open realtime
access to specific groups:

http://sourceforge.net/projects/realtime-lsm/

This still provides no privilege separation with respect to realtime
(note the comments in the README), but it doesn't enforce you to run all
RT-apps under root. So you keep at least the file system secure...

Given that this module plays with capabilities, it should work fine with
Xenomai as well (untested...).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

s.a. wrote:
> Hi,
> 
> In my mind , one or more rt process manages everything critical, need
> root access for resources reasons , other processes are things like gui
> to interact with realtime world, including  X11 applications (I know , I
> will hurt some people, but this is the truth : X11 !) .....
> 

My point is: what do you gain by separating the RT core from the logging
or gui application? Not much as long as the interface is not robust.
This means that your uncritical part must not be able to interfere with
the critical one, e.g. by acquiring some common lock or messing up a
shared memory which is used blindly by the RT code. If your application
design can guarantee this, ok.

But then note that Xenomai heaps are unsuited for being shared with not
fully trusted parties: management structures reside next to the data,
write permission is always acquired (and is required for
allocation/release operations), access control beyond go/no-go is not
supported. Better use "standard" (Linux) shared memory for this: Invoke
shm_open("myshm", ...), adapt the access rights of the newly created
/dev/shm/myshm, and let the unprivileged process attach to it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[s.a.]

Hi,

In my mind , one or more rt process manages everything critical, need
root access for resources reasons , other processes are things like gui
to interact with realtime world, including  X11 applications (I know , I
will hurt some people, but this is the truth : X11 !) .....


Best Regards
Steph
  


Jan Kiszka wrote:

>s.a. wrote:
>  
>
>>Hi,
>>
>>Okay, but in this case, why do we need  root permissions for programs
>>accessing that "only" access shared memory area (heaps)????
>>    
>>
>
>For simplicity reasons: we did not sort out at this stage which service
>might be harmless and which not (or less), we only added access control
>to all Xenomai syscalls. Again, you can switch the whole checking off
>during compile time, but this, of course, opens the door completely.
>Given your system is adequately secured against illicit logins, this can
>be a pragmatic solution.
>
>Ok, we might derive access control to the heap from the permissions a
>process has on /dev/rtheap. But is this an urging need to have security
>for all Xenomai services but heaps? Opening heaps would make access
>control more complicated without a clear security model behind it. But
>I'm always open to concrete user requirements!
>
>Jan
>
>  
>
>>Best Regards
>>Steph
>>
>>
>>Jan Kiszka wrote
>>
>>    
>>
>>>Petr Cervenka wrote:
>>> 
>>>
>>>      
>>>
>>>>Hi,
>>>>When I try to run realtime application under lesser than root rights, I get this strange error:
>>>>Xenomai: binding failed: Operation not permitted.
>>>>
>>>>Error showed after kernel update 2.6.15.6 -> 2.6.16.16 and xenomai update 2.1.1 -> daily snapshot (2006/05/18)
>>>>Changing of the rights of the /dev/rt* dousn't help.
>>>>
>>>>Any suggestions?
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>That's intended. Real-time means real power, so all skin syscalls now
>>>require root privileges (more precisely CAP_SYS_NICE). This can be
>>>switched off, but standard syscalls like mlockall may still demand root
>>>power (mlock'ing is at least size-limited for normal users on recent
>>>kernels). And with current real-time APIs, it makes no sense anyway to
>>>restrict the real-time user's permission by turning his account into a
>>>non-root one.
>>>
>>>Jan
>>>
>>> 
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Xenomai-help mailing list
>>>Xenomai-help@domain.hid
>>>https://mail.gna.org/listinfo/xenomai-help
>>> 
>>>
>>>      
>>>
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xenomai-help mailing list
>Xenomai-help@domain.hid
>https://mail.gna.org/listinfo/xenomai-help
>  
>

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[s.a.]

Hi,

Okay, but in this case, why do we need  root permissions for programs
accessing that "only" access shared memory area (heaps)????

Best Regards
Steph


Jan Kiszka wrote

>Petr Cervenka wrote:
>  
>
>>Hi,
>>When I try to run realtime application under lesser than root rights, I get this strange error:
>>Xenomai: binding failed: Operation not permitted.
>>
>>Error showed after kernel update 2.6.15.6 -> 2.6.16.16 and xenomai update 2.1.1 -> daily snapshot (2006/05/18)
>>Changing of the rights of the /dev/rt* dousn't help.
>>
>>Any suggestions?
>>
>>    
>>
>
>That's intended. Real-time means real power, so all skin syscalls now
>require root privileges (more precisely CAP_SYS_NICE). This can be
>switched off, but standard syscalls like mlockall may still demand root
>power (mlock'ing is at least size-limited for normal users on recent
>kernels). And with current real-time APIs, it makes no sense anyway to
>restrict the real-time user's permission by turning his account into a
>non-root one.
>
>Jan
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xenomai-help mailing list
>Xenomai-help@domain.hid
>https://mail.gna.org/listinfo/xenomai-help
>  
>

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

s.a. wrote:
> Hi,
> 
> Okay, but in this case, why do we need  root permissions for programs
> accessing that "only" access shared memory area (heaps)????

For simplicity reasons: we did not sort out at this stage which service
might be harmless and which not (or less), we only added access control
to all Xenomai syscalls. Again, you can switch the whole checking off
during compile time, but this, of course, opens the door completely.
Given your system is adequately secured against illicit logins, this can
be a pragmatic solution.

Ok, we might derive access control to the heap from the permissions a
process has on /dev/rtheap. But is this an urging need to have security
for all Xenomai services but heaps? Opening heaps would make access
control more complicated without a clear security model behind it. But
I'm always open to concrete user requirements!

Jan

> 
> Best Regards
> Steph
> 
> 
> Jan Kiszka wrote
> 
>> Petr Cervenka wrote:
>>  
>>
>>> Hi,
>>> When I try to run realtime application under lesser than root rights, I get this strange error:
>>> Xenomai: binding failed: Operation not permitted.
>>>
>>> Error showed after kernel update 2.6.15.6 -> 2.6.16.16 and xenomai update 2.1.1 -> daily snapshot (2006/05/18)
>>> Changing of the rights of the /dev/rt* dousn't help.
>>>
>>> Any suggestions?
>>>
>>>    
>>>
>> That's intended. Real-time means real power, so all skin syscalls now
>> require root privileges (more precisely CAP_SYS_NICE). This can be
>> switched off, but standard syscalls like mlockall may still demand root
>> power (mlock'ing is at least size-limited for normal users on recent
>> kernels). And with current real-time APIs, it makes no sense anyway to
>> restrict the real-time user's permission by turning his account into a
>> non-root one.
>>
>> Jan
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>  
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Petr Cervenka wrote:
> Hi,
> When I try to run realtime application under lesser than root rights, I get this strange error:
> Xenomai: binding failed: Operation not permitted.
> 
> Error showed after kernel update 2.6.15.6 -> 2.6.16.16 and xenomai update 2.1.1 -> daily snapshot (2006/05/18)
> Changing of the rights of the /dev/rt* dousn't help.
> 
> Any suggestions?
> 

That's intended. Real-time means real power, so all skin syscalls now
require root privileges (more precisely CAP_SYS_NICE). This can be
switched off, but standard syscalls like mlockall may still demand root
power (mlock'ing is at least size-limited for normal users on recent
kernels). And with current real-time APIs, it makes no sense anyway to
restrict the real-time user's permission by turning his account into a
non-root one.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] Xenomai: binding failed: Operation not permitted.

[Petr Cervenka]

Hi,
When I try to run realtime application under lesser than root rights, I get this strange error:
Xenomai: binding failed: Operation not permitted.

Error showed after kernel update 2.6.15.6 -> 2.6.16.16 and xenomai update 2.1.1 -> daily snapshot (2006/05/18)
Changing of the rights of the /dev/rt* dousn't help.

Any suggestions?

Petr Cervenka