Re: [Tails-dev] next big features: status update

Delete this message

Reply to this message
Author: anonym
Date:  
To: The Tails public development discussion list
New-Topics: [Tails-dev] source path's "/" prefix [Was: next big features: status update]
Subject: Re: [Tails-dev] next big features: status update
03/19/2012 08:09 AM, intrigeri:
> hi,
>
> anonym, what's the point of forbidding relative source paths such as
> "dotfiles" in the first column of live.persist?


I allowed relative source paths at one point, but I forbade it because
of dots. I really want to disallow the special dirs "." and ".." in
paths since they:

1. make it difficult to compare paths. (If busybox had a working
"readlink -f" this would not be much of an issue, but it doesn't.)
2. allow you to escape outside of the persistent media and cause all
sorts of fun.

For home-rw compatibility it must be possible to specify the media root,
e.g. "/" with the absolute paths, and "." relative paths, with the
latter being illegal according to my above requirement to disallow dots.
Our options are:

1. As an exception we could allow a single, lonesome "." to specify the
media root, while disallowing all other dots, but that feels highly
inconsistent, and it would make path comparisons more painful with
this extra special case.
2. We allow both absolute and relative paths, so "/" via absolute path
syntax is the only way to specify the media root. Allowing both seems
superfluous to me given that the absolute syntax can do everything.

I wouldn't expect either to make it any clearer for users, or easier for
t-p-s to understand live-persist files. Or am I mistaken? Do you have a
third alternative?

> I find it a bit weird. I think there's no such thing as an "absolute
> path wrt. the persistent media root", and this makes it harder to deal
> with user input on tails-persistence-setup's side, not to mention the
> burden on users themselves.


How can there be no such thing as an "absolute path wrt. X"? That's the
chroot concept.

> Can we easily and safely remove that requirement, and treat "gnupg"
> the same way as "/gnupg"?


It'd be easy to implement, but less easy to explain to users, imho.