Re: Minor security issue in copying permission bits

[Lasse Collin]

Paul Eggert wrote:
> Lasse Collin <address@hidden> writes:
> > Now the users in the "restrict" group will have access to foo.gz
> > although they didn't have access to the original foo file.
>
> First, the same problem applies to user permissions too, no?
> For example, if the original file is mode 066, the
> compressed copy will be writeable to the original user
> even though the original user doesn't own the copy and
> couldn't write the original file.

From practical point of view, the original owner always had all 
permission to access the original file. It was just a chmod away. 
That's why I think the problem doesn't apply to user permissions.

> Second, we don't need weird permissions to illustrate the problem of
> "unexpected" permissions-granting.  We can just have a file that's
> mode 660.  The copy will be in a different group, so users in that
> group will be able to access the file even though they couldn't
> access it before.

Yes, my example was too complicated.

> This same problem must afflict almost every program that invokes
> chown() or fchown().  It's not reasonable to make this change to all
> applications.  What we can do is tell users "don't use weird
> permissions like that, unless you really know what you're doing, and
> you probably don't".

I wonder how many programs copy permission bits as is. For example, "cp 
foo bar" copies permission bits but masks them with umask. You need to 
give -p to preserve everything as is. On the other hand, Konqueror 
seems to copy the permissions as is but doesn't preserve the GID even 
when it could.

The programs that need to copy the owner, group and permissions, would 
need some extra code to copy ACLs and EAs. While I still don't 
personally use those features, I guess that supporting them will be 
needed sooner or later. Adding support for ACLs and EAs is as 
(un)reasonable amount of work as making the copying of permission bits 
better.

I'm unsure what the better way would be though. Maybe using umask (like 
cp does without -p) when copying GID fails would be better solution 
than what I suggested with my patch. Or just ignore the whole problem 
since it doesn't exist in the most typical usage cases (copying the 
group usually succeeds or the user doesn't care).

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode