Eric Valette wrote on 18/02/2020:
> Package: fscrypt
> Version: 0.2.5-2
> Severity: normal
> Tags: upstream
>
> I have a pc backup script running rsync that runs as root. As a normal user I
> created
> a protected directory call it mysafe.
>
> When I do as a normal user ($USER)
>
> fscrypt unlock /home/$USER/mysafe
>
> I open the safe almost the fisrt time (pasword is long and I may make a typo
> once).
>
> When in the backup script, run as root I do:
>
> fscrypt unlock /home/$USER/mysafe --user=$USER
>
> I can enter the password twenty time without sucess.
>
> It was working well before I switched to fscrypt 2.5 and 5.4 kernel. I often
> need to log
> in and open safe as $USER as the script does:
>
> fscrypt status ${SAFE_LOCATION} | grep -q "Unlocked: Yes"
>
> before trying to unlock...
>
> I reported this upstream.
Hello Eric, thanks for your bug report. Three questions:
1. Are you sure that in your backup script $USER expands to the username
you want and not to 'root', given that you run it as root? You could try
adding a 'set -x' right after the script's shebang to check how the
commands are being called.
2. I just uploaded version 0.2.6-1 of the fscrypt package. Once the new
version becomes available in the archive could you check if the problem
is still present?
3. Could you provide a pointer to the upstream bug you filed?
Thanks!
Paride
