16.08.2011 15:52, intrigeri пишет:
> 1. The /var/lib/gdm3/tails.password file must not be created in a
> world-readable manner.
Fixed via os.chmod - didn't manage to make os.umask work for some reason.
> 2. The password is written to this file without any kind of quoting,
> then the file is interpreted by a shell. Seems obvious some kind of
> passwords won't work, doesn't it?
True. Now 'quote' from pipes module used.
Not sure if that's enough though.
> 3. set-user-password-and-locale error handling makes me doubtful.
> It seems to me such code is hiding fatal error conditions under the
> carpet:
>
> . /etc/live/config.d/username || exit 0
> if [ -z "${LIVE_USERNAME}" ] ; then
> exit 0
> fi
>
> How about echo'ing something to STDERR at least?
Simple file logging added. Maybe in future syslog should be used instead.
> 4. /etc/sudoers.d/ directory seems not enabled yet, but I think it
> should be unconditionally enabled at image build time by a
> chroot_local-hooks, rather than at logon time.
It seems to be enabled in squeeze by default: /etc/sudoers contain
'#includedir /etc/sudoers.d' directive.
If it's not enabled in tails than there's some code (in *hooks maybe) which disable
it. How can we find it?
> 5. namespace
>
> I see those files are deleted when no admin password was entered:
> rm -f /etc/polkit-1/localauthority.conf.d/52-tails.conf
> rm -f /etc/sudoers.d/tails.conf
> I understand why such cleanup is useful, but it reveals
> tails-greeter considers those files as its own files, it is the
> only one to manage, i.e. it takes over generic file names. I think
> s/tails.conf/tails-greeter.conf would be appropriate.
Fixed in git.
> 6. does not work twice-in-a-row
>
> When LIVE_USERNAME's has had a password set once by tails-greeter,
> then login, then logout, back at tails-greeter: tails-greeter does
> not allow login, presumably because it does its autologin with
> hardcoded password black magic tricks with the default / old /
> obsolete password. This is a blocker. Using regular GDM autologin
> functionality seems like the sane way to fix this.
Agree. Proper fix will take some time so I'll add it to known-issues list (yet to be
written).
> A quick'n'dirty way to hide the underlying problem, and have things
> working right now, is to reset the LIVE_USERNAME's password to the
> default one, in set-user-password-and-locale, in if [ -z
> "${TAILS_USER_PASSWORD}" ].
If we change password in set-user-password-and-locale than we effectively ignore
whatever user entered as password. Either I've misunderstood it or it's hardly a fix.
bye,
Max.
