Bug#332264: tex-common: permission-handling of ls-R files is one-way

[Frank Küster <frank@kuesterei.ch>]

Norbert Preining <preining@logic.at> wrote:

> I read through your proposal and have a hard time to understand it. I
> wrote a bit of PseudoCode what should be done. What do you think about
> this:

Sorry if I was unclear.  Maybe I'm also a bit confused.  Some of the
errors I found in your text below are actually mine...

> -------------------------------------------------------------------
> config file operation
> =====================
>
> fresh install: any mode -> use our defaults

ACK

> upgrade:
> non-interactive mode -> do nothing *at all*, not even ask anything

My mistake: We can't special case "non-interactive mode" - that's not
how debconf is meant to be used.  It is not a registry, it is only
intended to cache answers between running config and running postinst.
No config script should rely on the existense or correctness of answers
in the cache.

Therefore we cannot treat noninteractive special.  Debconf takes care
that no questions are asked to the user, but we must ask debconf for
answers and not care how it got them (from our defaults, from real
answers or by preseeding).

> interactive mode:
>     ask for which files should be managed by debconf
>         store in OldManagedLsrFiles files which have already been managed
>                 and are still managed

How do you know whether a ls-R file has already been managed?  You can't
rely on the old setting of the debconf question - that would be an abuse
of debconf ("debconf is not a registry").

Therefore I don't see how your outlined scheme could work, e.g.

>        # there is an old file which actually was modified from the
>        # debconf setting. We have to find it and ask the user what
>        # should happen with it! This is case (c) I would say

You cannot know what the previous debconf setting was!

I have thought it over, my proposal won't work either.  Here's an
alternative suggestion in pseudocode:

config
======

do ls-R files exist? If yes:

- get permissions and ownership of ls-R files for /var/cache/fonts,
  /var/lib/texmf and /usr/share/texmf

- sort these files into "664files" and "644files"

- check which files are in 664files, and db_set managedlsr to these
  files 

- db_input managedlsr, i.e. ask the question which files should be
  group-writeable.  Rephrase the question so that it asks about
  "writeable by *their* group".

- db_get managedlsr and change 664files to be the new selection

- for(664files){
    # (we don't care about the owner at all, we only handle group
    # permissions) 
    If SameGroup then {
        # in this case, we ask for group ownership and eventually change it
        CommonGroup=Group(664files)
        }
    else {
        # in this case, we don't ask about or touch group ownership
        CommonGroup=""
        }
  }

- db_set groupname Commongroup
  # i.e. it gets empty when they have not the same group

- If [ -n Commongroup ] then {
     # at this place, we could *maybe* introduce a new default.  I'm unsure.
     db_input groupname 
     }

postinst
========

- 664files="$RET of db_get managedlsr", 644files=allfiles NOT 664files

- for(664files) {chmod g+w}
  for(644files) {chmod g-w}

- groupname="$RET of db_get groupname"

- If [ -n groupname ] then { for(664files) {chown :groupname}} (else nothing)

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