Help with permissions under Rainbow sought

[George Hunt]

Sascha,

I'll plan to put the history in the Journal -- seems like a good idea.

I had looked for an input mechanism to Rainbow's CONSTANT_RAINBOW_UID
without success. So thanks for your pointer.

I'm curious to know why you think using a constant UID is undesireable.  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 a
source of failure, while I deal with all the other problems I haven't
foreseen, I can come back and tighten up security when my code is more
solid.

With much appreciation for your help,
George

On Sun, Apr 18, 2010 at 8:10 AM, Sascha Silbe <
sascha-ml-ui-sugar-olpc-devel at silbe.org> wrote:

> On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote:
>
>  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).
>>
> 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 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 [1] you'd need to add
> a file activity/permissions.info, containing "constant-uid" on a single
> line.
> This is the least preferable solution, though.
>
>
>  Apparently the create mask rainbow uses is 755 and group members do not
>> have write access.
>>
> It's not Rainbow that decides this. Permissions of newly created file
> system entries (i.e. files and directories) are determined by the umask (see
> e.g. "man 2 umask"). You can either widen the permissions after creation
> using chmod() (see "pydoc os.chmod") or tweak the umask (see "pydoc
> os.umask"); since the latter affects _all_ created files I would recommend
> the chmod() (you could save+restore the umask, but it's prone to race
> conditions).
>
>
> [1] http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLyvayAAoJELpz82VMF3Da4IoIAI+HUTUnCJWOrz0kk4reyDmh
> GaBNXbG/DbMSRf0EEKiXCVABzQahgKUFg7PKiIZY5xl+Qt5esPQ50KDlsPUZYG+K
> 972H9/VNRo+kTOZ9JuYGDzKsexwowparXLH7QFL9wZNy/+5eA2vy/qH6kKlKrarZ
> Qki9Comwxh6aRKqXhlrTQn5/IXA0FoXySjx37T8jW+hJTRe05QfKIJrsUVTks/t7
> BnviPWfrJHip2LIDmsChrVDPsibUKBvC7hGV+iEsbCUSQKpt+Nf97jWw8eWL+pbx
> tmUfNAuuI9CGpgoFsrJjZ3PUR/fvrcDJb9CvXEDz0+VorZuRiSN7tE2883yIXzY=
> =X+wE
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100418/0151d0b3/attachment.html>