Bug 11162 - IPFire does not support passwords with shell metacharacters
Summary: IPFire does not support passwords with shell metacharacters
Status: CLOSED WORKSFORME
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: Will only affect a few users Major Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-06 02:51 UTC by chrish
Modified: 2025-04-16 13:14 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chrish 2016-08-06 02:51:13 UTC
When a PPP account has a password that has shell metacharacters, the "PASSWORD" entry for that account gets filtered out by readhash, which causes the password in the secrets file to be an empty string. This obviously causes PPP not to work for these cases.
Comment 1 Peter Müller 2018-05-08 15:58:51 UTC
This was in the wrong category. Moved.
Comment 2 Adolf Belka 2025-03-08 14:45:01 UTC
Is this still a valid bug with the latest updates to ppp?
Comment 3 Adolf Belka 2025-03-12 17:14:24 UTC
I decided that I should be able to test it out on my vm system. I can't connect withy ppp as I don't have that option, however the description was saying that if a meta character was used in the password then the secrets file ended up without any password present at all.

I could not reproduce that.

I don't know which meta character was used by the bug reporter but I used the password

this^is$the|pass\word

which has 4 meta characters and that exact password ended up in the secrets file after saving the entry.

Looking through the pppsetup.cgi code the readhash commands are never used with the secrets file. They are however used with the settings file.

In my case again the correct password, including all the meta characters ends up in the settings file.

So I also have not been able to reproduce the effect by entering meta characters and then saving the profile.

The code uses readhash to access the values from the settings file, which have come from the WUI page, and then uses writehash to write those values to settings-1 for the first profile.

Then some of those values are written to the secrets file, getting the values from the variables that the previous readhash command(s) had provided. The values are written to the secrets file with a subroutine called writesecrets.

sub writesecrets
{
        # write secrets file.
        open(FILE, ">/${General::swroot}/ppp/secrets") or die "Unable to write secrets file.";
        flock(FILE, 2);
        my $username = $pppsettings{'USERNAME'};
        my $password = $pppsettings{'PASSWORD'};
        print FILE "'$username' * '$password'\n";
        chmod 0600, "${General::swroot}/ppp/secrets";
        close FILE;
}

So I believe that if the original poster had a problem with the secrets file ending up with any password entry at all, then some other issue than the use of meta characters was experienced.

For this bug to stay open it needs the original poster to indicate if they still have a problem with the use of meta characters, and if so which ones.
Comment 4 Adolf Belka 2025-04-16 13:14:44 UTC
As there has been no response back on this bug after 35 days then the bug is being closed.

If the bug is still valid then it can be re-opened with supporting information.