[pmwiki-users] How to test permissions for target of link?

Lars Eighner surname at larseighner.com
Tue Oct 11 08:31:45 CDT 2011

On Tue, 11 Oct 2011, Peter Bowers wrote:

> On Tue, Oct 11, 2011 at 12:02 AM, Lars Eighner <surname at larseighner.com> wrote:
>> I want to use PmWiki for genealogy. I want pages pertaining to persons to be
>> named according to the person's name.  I want pages pertaining to historic
>> (i.e. deceased and presumed deceased) persons and consenting adults to be
>> publically readable.  But I want to conceal the identities of living adults
>> who have not given me permission and living children so they appear only to
>> family members who have read permissions.
> I note that with these particular specifications you still have a
> security/privacy "leak".  Since you want security to be based on the
> *target*, someone could have edit or source privilege on the
> *originating* page and (since pages are named according to the
> person's name) they would still be able to see it.  If you eliminate
> source privileges and are OK with "edit" permission on the originating
> permission implying that they can view the names then you are OK.

Yes, default 'source' permission has been set to 'edit', and I am taking for
granted that I will grant 'edit' premission only to those who have
'read' permission for all pages. 'attr' permissions are locked, partly so I
can review the evidence that pages should be made public and partly because
even those who have the ability to edit can easily go wrong with attr and
accidentally or on purpose wreek more havoc than a security breech.

> If you want to keep to a strictly target-based security mechanism (as
> you've described above) then you will have to change to some other
> naming convention such as numeric or etc. with the *title* of the page
> being the person's name.  While this sounds complicated, a simple form
> could easily accomplish this and at the same time could standardize
> the type of information you are collecting (putting
> birthdates/locations into PTVs, etc.).

I do not think this is strictly necessary for the level of security I am
trying to achieve.  If precautions are taken against directory listing, I
don't see the problem in page file names being based on personal name.

This is a little bit like "I don't have to run faster than the bear. I only
have to run faster than you." Given that there is no absolute security and
that just about the information I have that might be useful to an intruder
comes from public sources, I am only aiming to make it harder to get it from
my site than to get it from the other sources -- since I cannot fix the
other sources.

> In other words, your page name would be 000001 but the title would be
> "(:title Sam Smith:)".  If your page name is "MyGroup.SamSmith" then
> an editor of this page will still see [[Sam Smith]] when he edits the
> page, even if he doesn't have read permission on Sam's page.
> Again, if edit permissions on the current page imply read permissions
> on links then this is all a moot point.  But I would still be very
> tempted to go with a form-based system for creating new pages (it will
> both standardize the input and also deal with the possible difficulty
> of having multiple names in the family that are the same).

After I hacked at things for several days to secure personal name based file
names to my satisfaction I came to the conclusion that a reference number
based system was really more sensible because in my ethnic group people are
seldom especially creative in naming.  Reference numbers are a pain, but it
seems much simpler than anything I can think of for dealing with the
frequent occurrence of identical names.

Although not a decisive point for me, because I am not especially enamored
of GEDCOM, a reference number based system makes importing or exporting
GEDCOMs, whether manually or automatically, a much easier task. There is
no viable competing standard for transmission of this kind of data.

Lars Eighner
8800 N IH35 APT 1191 AUSTIN TX 78753-5266

More information about the pmwiki-users mailing list