On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote:
> > XO and SoaS distributions are configured for sudo with no password.
>
> Yes. However, Uruguay does not maintain this configuration choice.
I'm very sorry about this.
> > Rainbow has been bit-rotting for the
g things constant-uid in the sugar-0.82 + rainbow-0.7.* world removes all
isolation between instances of the activity.
> At this point I'm looking for ways to simplify the next stages of debugging my
> program.
>
> My thinking is as follows: If I can get permissions off the table as
On 18.04.2010, at 17:10, Michael Stone wrote:
>
> Bert Freudenberg wrote:
>> On 18.04.2010, at 14:10, Sascha Silbe wrote:
>>> On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote:
>>>
>>>> Rainbow changes UID for every invocation [...]
>>&
Bert Freudenberg wrote:
>On 18.04.2010, at 14:10, Sascha Silbe wrote:
>> On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote:
>>
>>> Rainbow changes UID for every invocation [...]
>>
>> Yes, that's the default behaviour. Rainbow can be instruc
file to
>> the home directory (I changed the HOME environment to SUGAR_ROOT/data).
>>
> Have you considered saving the history as part of the data store entry
> instead? That way your activity wouldn't mix histories from separate
> sessions (i.e. when debugging several
ou considered saving the history as part of the data store entry
> instead? That way your activity wouldn't mix histories from separate sessions
> (i.e. when debugging several different programs).
>
>> Rainbow changes UID for every invocation [...]
> Yes, that's the d
way your activity wouldn't mix histories from separate
sessions (i.e. when debugging several different programs).
Rainbow changes UID for every invocation [...]
Yes, that's the default behaviour. Rainbow can be instructed to use a
constant UID (Browse does); according to the OLPC wiki
Hi all,
I've been trying, in the last few days, to put the finishing touches on the
PyDebug activity I have been developing. I am using an ipython console
application which writes a history file to the home directory (I changed the
HOME environment to SUGAR_ROOT/data). Rainbow changes UI
On Thu, Jan 14, 2010 at 06:51:34PM +0100, Martin Langhoff wrote:
> - on systems where earlier WikipediaES versions were started, Rainbow
> seems to remember the old "any uid" mode, and ignores the request for
> a persistent uid.
Interesting. Are you starting the activi
Working with the Rainbow we shipped in 8.2.1, and looking at
http://dev.laptop.org/ticket/8814#comment:19
Briefly, Wikipedia-xo packages have been seeing warnings from the
xulrunner engine (and some minor bugs) because they should use
"persistent-uid" in permissions.info... and they
On 22.12.2009, at 06:06, Michael Stone wrote:
>
> Friends,
>
> I am pleased to announce the release of rainbow-0.8.6. Rainbow implements
> portions of the isolation shell described in the Bitfrost threat model and
> security architecture.
>
> The key differences betw
Friends,
I am pleased to announce the release of rainbow-0.8.6. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.
The key differences between this release and its predecessor include support
for garbage collection of uids, ui
Bringing these very useful notes back to the list. Below, Michael
outlines steps-to-integrate...
On Sun, Nov 29, 2009 at 2:44 PM, Michael Stone
wrote:
>> If there was someone interested in
>> re-integrating rainbow into the stack, beyond the obvious of packaging
>> the latest
Friends,
I am pleased to announce the release of rainbow-0.8.5. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.
The key differences between this release and its predecessor are bug fixes,
preliminary support for network
Folks,
I've put together a new rainbow release, rainbow-0.8.4,
http://wiki.laptop.org/go/Rainbow
http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.4.tar.bz2
with three tasty new features which I think you might enjoy.
New Features
1) support for re
about the status of
where it stands within Fedora rawhide. The current understanding is
what's documented at this link. If you have more to provide that would
be great (I was already aware of rainbow and the PID changes but
didn't put details in as I don't know alot about early boo
> The main and probably most major issues outstanding are the
> kernel/boot process - so
> kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection
> of stuff of which I have no real idea about. Updates?
Peter,
Your remark does not contain any specific questions so it
hy and possibly dbus
>to support rainbow.
Peter,
You're confusing rainbow (the activity isolation component of Bitfrost) with
many other components including olpc-update, olpcrd, OFW, and hardware support.
Please read
http://wiki.laptop.org/go/Rainbow
and let me know if you're
t;> Reinventing the desktop as a constructivist learning environment is a big
>> enough task for one development team / community to swallow. Reinventing
>> security is an altogether separate cause.
>> That said, Rainbow exists, so we don't need to do anything to remove it. So
ch I fear is not the case
>at w.l.o). But for a subtle and complex feature such as Rainbow, good
>documentation would be a motivator for use both within and outside the sugar
>community.
Carol,
I can't promise that I've reached "clearly lays out" yet, but I /have/ work
> The userland application privilege
> isolation is hugely important, as we are pushing for making our apps
> heavily network oriented, the risks of other network hosts trying to
> take advantage of vulnerable apps is huge.
A problem with expandin
s from
> rogue applications.
> Reinventing the desktop as a constructivist learning environment is a big
> enough task for one development team / community to swallow. Reinventing
> security is an altogether separate cause.
> That said, Rainbow exists, so we don't need to do an
Tomeu Vizoso wrote:
> Michael,
>
> when several weeks ago you showed me in #sugar your patches to Sugar
> and explained the new rainbow concept, I told you that it seemed a
> good idea and that the patches looked pretty good.
>
> As you said Rainbow wasn't ready fo
On Wed, Feb 25, 2009 at 12:21 PM, Michael Stone wrote:
> For the record, "rainbow" only describes the userland privilege isolation
> part.
You're right. I conflated the overarching shadow of bitfrost with
rainbow. My bad.
> I think this would have the effect of making r
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote:
>remind me, Pippy's getting special case hack permission to drive a 8 line
>highway through Rainbow security permissions, right?
Unfortunately, no. No one has yet completed an implementation of the "gates"
need
lp me to understand their work whenever I took the time to
ask them questions every few months.
>It's hard to write a sandboxer like Rainbow, since it must not only appear
>to work, but be verified "secure" to a high degree of confidence. That's
>harder still if one is
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote:
>You are now talking about the implementation of rainbow that provides
>userland privilege isolation.
For the record, "rainbow" only describes the userland privilege isolation part.
The rest is just "OFW, olpc
On Tue, 24 Feb 2009, Benjamin M. Schwartz wrote:
> Martin Langhoff wrote:
>> Maybe my ignorance on matters selinux is showing? ;-)
>
> You are not alone. Sugar/OLPC simply never had SELinux experts who
> volunteered to work on Rainbow. We still don't (raise your hand if
Martin Langhoff wrote:
> Maybe my ignorance on matters selinux is showing? ;-)
You are not alone. Sugar/OLPC simply never had SELinux experts who
volunteered to work on Rainbow. We still don't (raise your hand if you
consider yourself proficient at writing SELinux policy!).
It's
On Wed, Feb 25, 2009 at 5:24 AM, Michael Stone wrote:
> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I
> have
> tried to clear the way for them to use it on all the platforms they care about
> by simplifying it, by making it more generically useful
but rather that _all_ desktop environments need it
(but currently lack it). In fact, I hope that other DEs will start using
Rainbow as well, even if just optionally.
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: Digital
On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote:
http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html
Thanks for your work! I sure hope it'll get used instead of dropped,
it's the #1 reason I looked into Sugar in the first place and the one
thing I miss mo
erything looks
> like a nail.
I do very much agree about back-ups (Martin's and others school-server
back-up work is in invaluable here), but the promise of Rainbow is not
just about limiting the possibilities for how a system could get
accidently/maliciously wrecked. For instance, how do
ids, not at people developing software or learning
how to do system administration.
> Backups are the correct solution to this problem, not some crazy security
> system. When all you have is a hammer, everything looks like a nail.
It seems to me your hammer is called "backup".
hat Sugar needs more protection than currently existing
> desktop environments, but rather that _all_ desktop environments
> need it (but currently lack it). In fact, I hope that other DEs will
> start using Rainbow as well, even if just optionally.
+1
Besides, if we didn'
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote:
>Hi Michael,
>
>2009/2/24 Michael Stone :
>> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it.
>
>How realistic is it to make rainbow something generic that all environments
>an
On Tue, 24 Feb 2009, Carol Farlow Lerche wrote:
> . the purpose (not in security speak but in terms of the benefits it brings
> to end users),
also why should rainbow be used instead of one of the many other sets of
tools available to distros for locking down a desktop (SELinux, or other
) struggled with is understanding which audiences
> require which sorts of documentation. Your continued assistance untangling
> this
> mess is most appreciated.
>
I would be happy to supply detailed editorial comments to any effort you
make to provide a unified Rainbow document.
... write
&
Hi Michael,
2009/2/24 Michael Stone :
> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it.
How realistic is it to make rainbow something generic that all
environments and applications could use? In an ideal world, such a
security system should be available to every
--- Wade Brainerd wrote:
> Backup, a far more useful and achievable
> solution to this problem.
I don't see how Rainbow, something _working_ and pretty usable on my XO right
now, is usefully compared to "backup", a solution similar in specificity to the
aphorism &quo
pparent) benefit
> to me or my program.
I'm going to bow out of this thread (back to work!) but I wanted to bring up
one last point regarding Rainbow's cost to Sugar.
It is my sincere hope that sometime in the future Sugar will gain the
ability to seamlessly launch normal X applications
bert wrote:
> On 24.02.2009, at 19:09, Carol Farlow Lerche wrote:
...
> > Asking for better documentation doesn't imply that the facility is
> > new. It recognizes that development has reached a local minimum in
> > an important component that is not well understood by many. My post
>
o think about Rainbow *at all* and things
Just Worked.
For simple activities and/or barrier-to-entry discussions, that observation
seems germane.
Martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote:
>Michael, I think your work on Rainbow is very important, but I think it is a
>bit opaque.
Carol,
Thanks you for this detailed critique of my documentation efforts to date. One
thing that I've (obviously) strugg
On 24.02.2009, at 19:09, Carol Farlow Lerche wrote:
> Bert, Are you satisfied with the number of activity developers?
> Are you satisfied with the number of developers within the
> deployments? Have you noticed the periodic questions on the
> developer-oriented lists a
Bert, Are you satisfied with the number of activity developers? Are you
satisfied with the number of developers within the deployments? Have you
noticed the periodic questions on the developer-oriented lists about Rainbow
security and whether it is causing mysterious symptoms? I'm not,
xing or other new security techniques, I
just argue that their purpose is *orthogonal* to the goals of Sugar.
Apologies for incorrectly assuming that you wanted someone to finish
Rainbow. As far as I know the current implementation is without major
issues, if some of the more advanced features of Bitfrost
oncentrated use of these features.
>That said, Rainbow exists, so we don't need to do anything to remove it. So
>long as people step up to maintain it and help activity developers fix the
>issues they run into.
The issue is that rainbow "has been maintained" and it
On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz <
bmsch...@fas.harvard.edu> wrote:
> They are a single, indivisible cause, and also the entire reason for the
> existence of Sugar.
>
> Many operating systems provide users with a set of powerful tools for
> manipulating ideas and data. Sugar
Hi Carol,
you make it sound as if Rainbow was new and unknown and Michael was
pushing it. That's a bit unfair. Rainbow has been shipping in the OLPC
releases for quite a while, and activity authors in general do know
that they simply have to respect the designated directories for s
sort, Sugar has
little to recommend it over XFCE and similar gtk-based iconic user
interfaces. We are getting there, and with the latest improvements to
view-source and Rainbow, we are beginning to have the basics in place.
--Ben
signature.asc
ivist learning environment is a big
enough task for one development team / community to swallow. Reinventing
security is an altogether separate cause.
That said, Rainbow exists, so we don't need to do anything to remove it. So
long as people step up to maintain it and help activity develope
Rainbow in jhbuild would help debugging. I don't think I am along=e in
using it as a development environment.
-walter
On Tue, Feb 24, 2009 at 12:09 PM, Michael Stone wrote:
> On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote:
>> On Tue, Feb 24, 2009 at 11:24:37AM -0500,
eally helpful to hear that someone
thinks this work is worth pursuing.
> What exactly do I need to do to try it out within sugar-jhbuild on
> Ubuntu intrepid (amd64)?
Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is
that you should teach jhbuild to c
Michael,
when several weeks ago you showed me in #sugar your patches to Sugar
and explained the new rainbow concept, I told you that it seemed a
good idea and that the patches looked pretty good.
As you said Rainbow wasn't ready for 0.84, I told you that we would
talk again when work on
Michael, I think your work on Rainbow is very important, but I think it is a
bit opaque. Perhaps you could improve your documentation and as well write
a tutorial about it that would make it more apparent how much is actually
implemented and what an activity can do with it.
So here's an ex
Michael Stone wrote:
> In my view, it's up to the SugarLabs folks to use Rainbow or to drop it.
Now that Sugar was made more modular, I think it's up to the
individual distributors to make a choice. It might be enabled by
default on XOOS, disabled by default on F11, and so on.
&g
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote:
>[Also, I'm hearing whispers of 'no Rainbow' after Joyride.]
Mikus,
In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have
tried to clear the way for them to use it on all the platf
Folks,
Bernie has been gently pushing me to revive some of my older security
work. To that end, we've pushed the first versions of rainbow-0.8.x into
Ubuntu [1] and Fedora [2], rebased the necessary sugar patches [3], and
rewritten my sys_disablenetwork() attempt into cool new RLIMIT_NETWORK
Hi,
rainbow's python module preloading causes a lot of activity breakage
in joyride (any activity based on gstreamer such as Record, Chat,
etc). Some reasons are detailed here:
http://dev.laptop.org/ticket/9035
I just released rainbow-0.7.27 which turns off preloading. It will be
in the
>> into activity window.
>>
>
>
> Could you replace the attached files in your XO (/usr/bin/olpc-session
> and /usr/lib/python2.5/site-packages/rainbow/service.py) and test ?
> (ideally rainbow should be enabled)
>
> I tested with scim-anthy, and it works for
hy.
> Now installation is straightforward with yum.
> While it is also affected by isolation, I can activate it and input
> Japanese string
> into activity window.
>
Could you replace the attached files in your XO (/usr/bin/olpc-session
and /usr/lib/python2.5/site-packages/rainbow/ser
Wow - what a coincidence - I have been working on the same thing for
the past one week :-D
I think I got the m17n input methods working - I'll check if SCIM
anthy works or not.
Thanks,
Sayamindu
On Sat, Nov 1, 2008 at 9:08 AM, Korakurider <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I have difficulty to
Hi.
I have difficulty to make Japanese input method (SCIM-anthy) work on 8.2-767.
Input method can't be activated on activity window even if hit
Ctrl-Space (IME on/off switch).
After some experiment I found that IME can be activated if activity
isolation is disabled.
If isolation is enabled, I can
Hi,
> 1.) imaged a machine using the salute method via usb to gg-767-4.
> 2.) Launch wiki-browse
> 3.) Click on 'technology' category link (this link important?)
> 4.) hangs and/or popup window complaining about a Rainbow Policy
> Issue.
>
?)
>
> 4.) hangs and/or popup window complaining about a Rainbow Policy Issue.
>
> 5.) Close and reopen
>
> 6.) Rainbow Policy Issue window comes back up.
>
> I grabbed another machine and attempted the activity again and got roughly
> the same result.
>
> Did w
http://dev.laptop.org/ticket/8814
This is a pretty big deal.
1.) imaged a machine using the salute method via usb to gg-767-4.
2.) Launch wiki-browse
3.) Click on 'technology' category link (this link important?)
4.) hangs and/or popup window complaining about a Rainbow Policy
Bert Freudenberg wrote:
> I've never seen a "rainbow-daemon" dialog before, what is it supposed
> to do? It doesn't work anyway, I filed a ticket with screenshot:
>
> http://dev.laptop.org/ticket/8435
I filed http://dev.laptop.org/ticket/7930 about another Brows
I've never seen a "rainbow-daemon" dialog before, what is it supposed
to do? It doesn't work anyway, I filed a ticket with screenshot:
http://dev.laptop.org/ticket/8435
- Bert -
___
Devel mailing list
Devel@lists.laptop.org
htt
On Thu, Aug 21, 2008 at 12:24 PM, Michael Stone <[EMAIL PROTECTED]> wrote:
> The other change we could consider would be to rev the isolation spool
> version number from 1 to 2 in Rainbow and in the Datastore. There is a
> small risk that other people might have hardcoded th
The other change we could consider would be to rev the isolation spool
version number from 1 to 2 in Rainbow and in the Datastore. There is a
small risk that other people might have hardcoded the
'/home/olpc/isolation/1' path but this should be contro
gt; joyride-2298 and vice versa
>>> (using alternate boot).
>>> After switching back from joyride-2298 to Update.1 most activities do
>>> not start because
>>> their home directory does not exist.
>>> I need some pointers where to look in rainbow how to get
>>After switching back from joyride-2298 to Update.1 most activities do
>>not start because
>>their home directory does not exist.
>>I need some pointers where to look in rainbow how to get this two way
>>switching working.
>>Anything I can run in Update.1 or rpm to up
start because
> their home directory does not exist.
Besides the rainbow issues, I think that the Datastore storage has
incompatible change.
When you upgrade, the new datastore upgrades to a new storage format.
When youdowngrade, the old datastore doesn't understand it so it moves
.suga
I don't think we want to pick up maintenance of this kernel patch...
- Jim
On Sat, 2008-08-16 at 18:32 -0400, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> victor wrote:
> | Is that documented? I don't see it in man page. I can try it, if
> |
most activities do
>> not start because
>> their home directory does not exist.
>> I need some pointers where to look in rainbow how to get this two way
>> switching working.
>> Anything I can run in Update.1 or rpm to update to get this working ???
>> One th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
victor wrote:
| Is that documented? I don't see it in man page. I can try it, if
| I have a code example (says there it does not take a priority
| value, so is it just a matter of setting the policy?)
Unfortunately, SCHED_ISO is only available in a pa
e" <[EMAIL PROTECTED]>
To: "victor" <[EMAIL PROTECTED]>
Cc: "Jim Gettys" <[EMAIL PROTECTED]>;
Sent: Saturday, August 16, 2008 10:39 PM
Subject: Re: rainbow and pam
> On Sat, Aug 16, 2008 at 10:15:08PM +0100, victor wrote:
>> Aren't these p
a process w/
CAP_SYS_RESOURCE) like login or su to call setrlimit() before running
some user-supplied code. Rainbow can accomplish this directly.
Michael
(I am interested in arguments as to whether Rainbow should be made to
interact with PAM and the 'login'/'session'/'term
uot;Michael Stone" <[EMAIL PROTECTED]>
Cc: "victor" <[EMAIL PROTECTED]>;
Sent: Saturday, August 16, 2008 10:27 PM
Subject: Re: rainbow and pam
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Michael Stone wrote:
> | According to "man sched_setsc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Stone wrote:
| According to "man sched_setscheduler" you want either CAP_SYS_NICE or a
| non-zero RLIMIT_RTPRIO and giving these to you means that you can
| hardlock the machine anytime by busywaiting.
As noted in a conversation with Michael,
TECTED]>;
Sent: Saturday, August 16, 2008 8:40 PM
Subject: Re: rainbow and pam
> According to "man sched_setscheduler" you want either CAP_SYS_NICE or a
> non-zero RLIMIT_RTPRIO and giving these to you means that you can
> hardlock the machine anytime by busywaiting. Audio p
According to "man sched_setscheduler" you want either CAP_SYS_NICE or a
non-zero RLIMIT_RTPRIO and giving these to you means that you can
hardlock the machine anytime by busywaiting. Audio performance is
clearly important to us in this release -- probably more important than
stopping random malicio
>>>> I was curious to see (when testing in joyride-2301) that rainbow
>>>> (python /usr/sbin/rainbow-daemon) seems to be the process that's
>>>> eating the most CPU cycles during an activity launch.
>>>
>>> Well, rainbow does a little bit of
Sorry if I was not clear. Here is the code that currently fails
under rainbow:
/* set scheduling policy and priority */
if (priority > 0) {
p.sched_priority = priority;
if (sched_setscheduler(0, SCHED_RR, &p) != 0) {
csound->Message(csound,"csound: cannot
But as it is, if you are playing MIDI or audio through an Activity launched
by rainbow, there is no way AFAIK you can renice it. The
code I am testing was set to either change scheduler priority
or to renice the process. None is possible.
Note that what I am proposing here would not affect you
Hi Gary
On Fri, 2008-08-15 at 23:18 +0100, Gary C Martin wrote:
> Hi Michael,
>
> On 15 Aug 2008, at 21:58, Michael Stone wrote:
>
> > On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote:
> >> I was curious to see (when testing in joyride-2301) that rainbo
> Proper fix: make the kernel have a per-task inheritable upper
> limit on the real-time priority. Perhaps the existing limit
> (used for niceness) can even do the job. It's this thing:
I almost always have multiple sessions running on my XO. If one of
those sessions provides me with background
Jim Gettys writes:
> Victor needs some way to be able to set the real time features
> of Linux; this is certainly desirable in various audio, voip
> and similar applications.
Quick fix: eliminate the restriction in the kernel
While this causes obvious problems for shared multi-user
machines, it
On Fri, Aug 15, 2008 at 09:14:47PM -0400, Jim Gettys wrote:
>Michael,
>
>I detect a disconnect.
The disconnect is that Victor has neither explained what syscalls he
wants to be able to make nor posted his patch to limits.conf. Until he
does one of these things, I am unable to help him.
Michael
__
linux.
It seems reasonable to me that Rainbow should provide a way for a bundle
to declare such needs
- Jim
On Fri, 2008-08-15 at 19:00 -0400, Michael Stone wrote:
> On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote:
> >I'm trying to get my head round ho
minal).
Victor
- Original Message -
From: "Michael Stone" <[EMAIL PROTECTED]>
To: "victor" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, August 16, 2008 12:00 AM
Subject: Re: rainbow and pam
> On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote:
>>I'
minal).
Victor
- Original Message -
From: "Michael Stone" <[EMAIL PROTECTED]>
To: "victor" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, August 16, 2008 12:00 AM
Subject: Re: rainbow and pam
> On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote:
>>I'
On Fri, Aug 15, 2008 at 11:52:59PM +0100, victor wrote:
>I'm trying to get my head round how rainbow works and there is one
>thing I cannot figure out. Why is that the UIDs generated by rainbow
>do not have the same resource access privileges as other UIDs as
>set in limits.conf
I'm trying to get my head round how rainbow works and there is one
thing I cannot figure out. Why is that the UIDs generated by rainbow
do not have the same resource access privileges as other UIDs as
set in limits.conf for pam? If I use a wildcard to match all users,
the UIDs set by rainbo
Hi Michael,
On 15 Aug 2008, at 21:58, Michael Stone wrote:
> On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote:
>> I was curious to see (when testing in joyride-2301) that rainbow
>> (python /usr/sbin/rainbow-daemon) seems to be the process that's
>>
On Fri, Aug 15, 2008 at 07:31:28PM +0100, Gary C Martin wrote:
>I was curious to see (when testing in joyride-2301) that rainbow
>(python /usr/sbin/rainbow-daemon) seems to be the process that's
>eating the most CPU cycles during an activity launch.
Well, rainbow does a little
I was curious to see (when testing in joyride-2301) that rainbow
(python /usr/sbin/rainbow-daemon) seems to be the process that's
eating the most CPU cycles during an activity launch.
Is this related to the faster stream changes where modules are loaded
early by rainbow so that
eir home directory does not exist.
>I need some pointers where to look in rainbow how to get this two way
>switching working.
>Anything I can run in Update.1 or rpm to update to get this working ???
>One thing I noticed is that /etc/group does not have all the groupids in
>Update.1
For my testing for trac #7788 I want to switch from Update.1 to
joyride-2298 and vice versa
(using alternate boot).
After switching back from joyride-2298 to Update.1 most activities do
not start because
their home directory does not exist.
I need some pointers where to look in rainbow how to
1 - 100 of 138 matches
Mail list logo
