Permissions in builds

Permissions in builds

[Gábor Boskovits]

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

I have seen, that several package definitions add write permissions to
files in the build.

I just had a package, where this issue came up. (python-networkx2)

The first issue I had was that in the build log the filenames were
truncated in the stacktrace.
Do we have any mean to avoid that? It would help to find the problematic
files.

It might not be a big issue currently, but it seems, that upstreams are
sometimes tighten permissions.
I think we could be more roboust to this if we could make sure, that we
have write permissions when we open something for writing in the build
system.

At first I thought that the best way would be something like this:
check permission of file, if no good, then add write permission, do the
modifications, then reset permissions to the state before.

Then I got a comment that files become read-only after they have been
installed in the store anyway from Marius Bakke.

So it seems, that reseting the permissions is not needed.

Then I thought, that maybe we could simply add write permission
unconditionally. That might be easy to implement. If it really has no
security implications, then the only drawback I see, is that some tests
might fail, if they check that permissions are strict.

WDYT?

We could also enable execute for directories unconditionally.

If this is good, then where in the build could such a step be implemented?

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

Re: Permissions in builds

[Chris Marusich]

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

Gábor Boskovits <boskovits@gmail.com> writes:

> I just had a package, where this issue came up. (python-networkx2)

Are you talking about this thread?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29146

It looks like the problem you are talking about is that certain gzip
files were not writable during the build, so the reset-gzip-timestamps
phase failed.  Is that right?  If so, it seems to me that the solution
is probably this: modify the logic of the reset-gzip-timestamps phase so
that before it resets the timestamp for a gzip file, it first chmods it,
then resets the timestamp, and then restores the original permissions.
You can probably find the code for the reset-gzip-timestamps phase by
grepping for that string in the Guix source tree.

> The first issue I had was that in the build log the filenames were
> truncated in the stacktrace.
> Do we have any mean to avoid that? It would help to find the problematic
> files.

I don't see that issue in the bug report or in the latest build logs:

https://mirror.hydra.gnu.org/log/i6c6ms1m1p7k56zla5m2d98cfbkhlcra-python-networkx2-2.0

Can you provide steps to reproduce the truncation you saw?  That would
allow us to investigate further.

> It might not be a big issue currently, but it seems, that upstreams
>are
> sometimes tighten permissions.
> I think we could be more roboust to this if we could make sure, that we
> have write permissions when we open something for writing in the build
> system.
>
> At first I thought that the best way would be something like this:
> check permission of file, if no good, then add write permission, do the
> modifications, then reset permissions to the state before.
>
> Then I got a comment that files become read-only after they have been
> installed in the store anyway from Marius Bakke.
>
> So it seems, that reseting the permissions is not needed.

Maybe.  In the interest of leaving no trace, it seems like a good idea
to restore the original permissions exactly as they were, even if Guix
will later make all of the files read-only.

> Then I thought, that maybe we could simply add write permission
> unconditionally. That might be easy to implement. If it really has no
> security implications, then the only drawback I see, is that some tests
> might fail, if they check that permissions are strict.

It shouldn't be too difficult to check the permissions of the gzipped
files first, then update their permissions if necessary, and then
restore the original permissions.

> We could also enable execute for directories unconditionally.

Why would we need to do that?  The reason we need to do it for gzip
files is so we can reset timestamps.  Is there a similar need to modify
directories?  I am unaware of any reason we need to do that for
directories, but perhaps I am missing some information.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]