Re: [gentoo-alt] permission test

[Burcin Erocal]

On Tue, 18 Oct 2011 20:45:50 +0200
Fabian Groffen <grobian@g.o> wrote:

> On 18-10-2011 20:34:12 +0200, Burcin Erocal wrote:
> > > >  	# Now we look for all world writable files.
> > > > +	if [ "${QA_SKIP_WRITABLE-unset}" == unset ] ; then
> > > >  	local i
> > > >  	for i in $(find "${D}/" -type f -perm -2); do
> > >
> > > How would this work, if you changed the D into ED here?  Checking
> > > files outside of our control is indeed not really useful.
> >
> > In that context, printing $D gives $PORTAGE_TMP/$CATEGORY/$P/image
> > in the prefix. Since these are the new files introduced by the
> > ebuild, I don't think we need to change that line. Note that this
> > is already in the portage sources and I didn't touch it. :)
>
> Ok, ED doesn't make a difference here.  Can you explain why the host
> system is making world-writable files?  What's its rationale to force
> that on you?  Can't you really not just sanitise that (your umask?)

The message below wasn't distributed to gentoo-alt@, probably since
Alexander is not subscribed to the group.


Begin forwarded message:

Date: Wed, 19 Oct 2011 01:12:53 +0200
From: Alexander Dreyer <alexander.dreyer@×××××××××××××××.de>
To: Burcin Erocal <burcin@××××××.org>
Cc: gentoo-alt@l.g.o
Subject: Re: Fw: [gentoo-alt] permission test


Hi Burcin,
> can you provide more information about the file system that requires
> the change for the world writable check?
>
> I remember something about making files accessible to the group, but I
> don't think I can describe the reason sufficiently.
The file system itself is nothing special, but it is hosted by a 
standalone file server which is exported to our Linux servers. But the 
problem is not cause by a technical issue, but by a social one:

We have shared directories which can only be accessed by a certain
group of users. The access is managed by ACLs on the toplevel
directory, s.th. only permitted users gain access to the latter and its
child directories. Unfortunately the group of users is not a unix group
- this would not be possible because different projects gain various 
combinations of people. So in order to allow collaboration, files have 
to have world read/writable permissions.
(Anyway I do not have influence on this setup.)

You can change these permissions afterwards, but newly generated files 
are world-writable in the first (this is enforced by the file server). 
Of course only formally, because the access is restricted by the 
toplevel ACLs.

Please note, that the problem only occurs for generated files, whose 
permissions are never set (using chmod, install or untar sufficies to 
fix the isuue). So I would consider this as a bug of those packages, 
respectively.

BTW: I didn't try out, but FAT-based USB drives often enforce 
world-writable mounts also.

It would already help me a lot, if the warning would not sleep for a
second.

My best,
   Alexander