Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
[Solved] Question about building shadow package on Debian
- stevepusser
- Posts: 12930
- Joined: 2009-10-06 05:53
- Has thanked: 41 times
- Been thanked: 72 times
Re: Question about building shadow package on Debian
Why can't you paste the build output showing what's going with the patches, then? Like I can?
MX Linux packager and developer
Re: Question about building shadow package on Debian
Hi,
I think I found the solution.
I didn't think of using "strings" to check the contents of the binary, I validated or not the good functioning of my binary with "strace".
This allowed me to see that my modified string (/etc/test/passwd) was present in the binary compiled.
I also noticed that the binary compiled "by hand" didn't load the PAM module during the build unlike the build done with "debuild".
After some research, I saw that these same absolute paths (/etc/{passwd, shadow}) are also present in the shared libraries of the libpam-modules package :
I think that's why the hand-compiled binary works, because it doesn't use the paths present in the shared libraries.
The "strace" of the binary made with debuild always returns the old paths (/etc/{passwd, shadow}) because they are overloaded by the PAM module.
The solution is to also recompile the libpam-modules package, but it's a complex solution because the modifications are not easiest (code + dependencies).
Thanks for your help.
P.
I think I found the solution.
I didn't think of using "strings" to check the contents of the binary, I validated or not the good functioning of my binary with "strace".
This allowed me to see that my modified string (/etc/test/passwd) was present in the binary compiled.
I also noticed that the binary compiled "by hand" didn't load the PAM module during the build unlike the build done with "debuild".
After some research, I saw that these same absolute paths (/etc/{passwd, shadow}) are also present in the shared libraries of the libpam-modules package :
Code: Select all
$ strings /lib/x86_64-linux-gnu/security/pam_* | grep "shadow\|passwd"
The "strace" of the binary made with debuild always returns the old paths (/etc/{passwd, shadow}) because they are overloaded by the PAM module.
The solution is to also recompile the libpam-modules package, but it's a complex solution because the modifications are not easiest (code + dependencies).
Thanks for your help.
P.