[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tex-common and ls-R files



Norbert Preining <preining@logic.at> wrote:

> Hi Frank!
>
> On Sam, 05 Nov 2005, Frank Küster wrote:
>> Now, if one file is already group-writeable and you do dpkg-reconfigure,
>> and you deselect all of them,  you get the message  "Leaving permissions
>> of ls-R files as they are ...".  
>> 
>>       falsegwritefiles="var cache main"
>> 
>> What do you think?
>
> No, I wouldn't suggest this. Why: User X changes the permissions of the
> ls-R files in a way he likes. And *after* this calls dpkg-reconfigure.

I don't agree here.  The decision in this question is a "binary" one for
each of the ls-R files - either they are group-writable, or they are
not.  If the user has changed the permissions (we only consider group
write permissions here) manually, the defaults in the question will
reflect just the state of the system as it is: The currently
group-writable files will be selected.  So if gets to that question and
deselects them all, why shouldn't we follow that wish and make them all
non-group-writable?  What's the difference here to a situation where all
are group-writable and he *only* deselects main and var, but keeps cache?

> I guess as soon as the user has deselected *all* ls-R files we should do
> *nothing* at all with permissions, even if we are sure we have set them
> or it would be wise.

If he has manually made them non-group-writable, we should respect this
(and we do already, in the sense that none will be selected in the
question).  But if he wants to make them non-group-writable, using the
same interface he used to make them group-writable before, why shouldn't
we respect this?  

Currently, if the admin comes to the conclusion that having
group-writable ls-R files is a security risk, but he wants to take the
risk for /var/cache/fonts/ls-R, he can make his system more secure with
dpkg-reconfigure tex-common.  But if he also wants to make the font
cache non-group-writable (and e.g. call allcm/allec manually), he
can't. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: