hi,
anonym wrote (19 Mar 2012 09:50:56 GMT) :
> 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:
[...]
I wholeheartedly agree with forbidding "." and "..".
> 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:
[...]
> 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.
Allowing to type less weird characters seems superfluous given than
typing more works? Am I the only one who remains unconvinced?
> I wouldn't expect either to make it any clearer for users,
I believe removing useless rigid requirements from a system generally
make it easier to understand and feel at ease with.
> or easier for t-p-s to understand live-persist files.
Sure.
>> 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.
Fair enough, that concept does exist :)
However, I would not like writing user documentation and realizing
I need to explain the chroot concept so that the way paths must be
expressed makes sense to anyone who has a basic understanding of how
relative and absolute paths work; see bellow for my proposal that
should avoid that situation.
>> 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.
I want to have to explain the minimal possible amount of concepts and
requirements. I want Tails users to be able to express "I want the
directory 'src' on my persistent storage volume to be mapped to the
directory '.dst' in my Tails $HOME", without ever knowing if, and why,
'src' should be prefixed by a "/".
So, let's forget about changing live-boot, and come take a walk with
me where I live these last days, that is: in GUI land.
Effectively, in the current state of things, to avoid causing
confusing behaviour later on ("I added a custom config but it's not
taken into account"), t-p-s should prevent the user from entering
a "source" that does not start with "/".
One way to do so would be to add the needed sanity check, and display
an error dialog (if needed) that painfully explains to users that they
must absolutely use the "/" prefix because that's how the world is.
Urgh urgh. Another way would be for t-p-s to add the leading "/" all
by itself if missing. I'm very much tempted to take the latter path,
which means, to support source paths without leading "/" at t-p-s
level, without ever exposing such evil paths to live-boot. This way,
live-boot must not be changed, and we don't need to explain anywhere
that "Thou Shall Use A Leading Slash In Source Paths".
What do you think?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Then we'll come from the shadows.
