[hylafax-users] PAM authentication and JobProtection
Giuseppe Sacco
from what I understand, in a default installation all users may access
faxes sent by anyone. In order to let all user see only their sent
faxes, I need to set PublicJobQ to false in hfaxd.conf and setup the
desired rights with JobProtection in the same configuration file.
All this configuration works when all users have an assigned unique or
shared uid. The uid is set in file hosts.hfaxd and defaults to 21 (the
unix "fax" group). The uid is not really meant as a user but as a group.
In fact the uid specified in hosts.hfaxd is used as unix group id when
creating files for a fax job. Files in sendq/ will have as unix uid uucp
and as unix gid the hylafax uid.
Now, I have a setup where I need to get user credentials from an LDAP,
so I configured hylafax for checking credential via pam. It works well.
But then it seems hylafax uid is always 60002, for all users. So the
PublicJobQ and JobProtection are useless. As explained in hosts.hfaxd
man page, 60002 is a default value for users without uid.
Is there any solution for this setup?
Thanks,
Giuseppe
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-us...@hylafax.org < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sa...@ifax.com.*
Lee Howard
> Now, I have a setup where I need to get user credentials from an LDAP,
> so I configured hylafax for checking credential via pam. It works well.
> But then it seems hylafax uid is always 60002, for all users. So the
> PublicJobQ and JobProtection are useless. As explained in hosts.hfaxd
> man page, 60002 is a default value for users without uid.
>
> Is there any solution for this setup?
Currently I do not think that there is any way for JobProtection to be
useful when using an authentication mechanism other than hosts.hfaxd.
For example, PAM never provides a uid or gid back to the application.
The direct-LDAP (without PAM) authentication found in HylaFAX+ is
similar... it provides authentication services, but there's no uid/gid
passed back to the application (hfaxd).
Consequently for this to be resolved hfaxd would need to automatically
add entries to hosts.hfaxd (or some other database/table/file) which
could be used to assign unique uid/gid to each user, but which would not
replace or interfere with future authentications. So some development
would be required to enhance and expand hfaxd to do this.
Thanks,
Lee.
Giuseppe Sacco
thanks for your prompt reply.
Il giorno gio, 09/12/2010 alle 21.14 -0800, Lee Howard ha scritto:
[...]
> Consequently for this to be resolved hfaxd would need to automatically
> add entries to hosts.hfaxd (or some other database/table/file) which
> could be used to assign unique uid/gid to each user, but which would not
> replace or interfere with future authentications. So some development
> would be required to enhance and expand hfaxd to do this.
Do you think a new attribute in ldap would help? I mean, it would be
possibile to add a faxGroup attribute to the currently used LDAP schema
(is it posixUser?) and use it as hylafax uid? Of course it will not be
usable via PAM, but it could be used when hylafax+ directly access LDAP.
Moreover, I just checked ldap authentication in hylafax+ source code.
From what I understand, this only works on LDAP schema that have a
groupMembership (is it Novell eDirectory schema?). It would not work on
posixGroup as they use memberUid attribute instead. Is it correct?
Bye,
Giuseppe
Lee Howard
> Hi Lee,
> thanks for your prompt reply.
>
> Il giorno gio, 09/12/2010 alle 21.14 -0800, Lee Howard ha scritto:
> [...]
>
>> Consequently for this to be resolved hfaxd would need to automatically
>> add entries to hosts.hfaxd (or some other database/table/file) which
>> could be used to assign unique uid/gid to each user, but which would not
>> replace or interfere with future authentications. So some development
>> would be required to enhance and expand hfaxd to do this.
>>
>
> Do you think a new attribute in ldap would help? I mean, it would be
> possibile to add a faxGroup attribute to the currently used LDAP schema
> (is it posixUser?) and use it as hylafax uid? Of course it will not be
> usable via PAM, but it could be used when hylafax+ directly access LDAP.
>
Yes, this is certainly possible, but I think it requires code
development work. And in my way of thinking if someone is going to do
some development work for this then that could be best-spent
implementing a feature that works for all authentication methods (both
PAM and LDAP). So that's how I'd spend *my* time trying to resolve it
rather than developing something specific to LDAP.
I've added Joshua Kinard, the HylaFAX+ LDAP contributor, to this e-mail.
Joshua, with the current LDAP implementation in HylaFAX+ does hfaxd get
some kind of unique per-user uid or gid and then pass that back to
hfaxd? (Forgive me for not re-examining the code.) If not, do you have
any opinions on its implementation?
> Moreover, I just checked ldap authentication in hylafax+ source code.
> From what I understand, this only works on LDAP schema that have a
> groupMembership (is it Novell eDirectory schema?).
I think it was developed for Microsoft Active Directory and also Novell.
> It would not work on
> posixGroup as they use memberUid attribute instead. Is it correct?
I don't know the answer to this question, but by all means the feature
could be expanded.
Thanks,
Lee.
Aidan Van Dyk
>> Do you think a new attribute in ldap would help? I mean, it would be
>> possibile to add a faxGroup attribute to the currently used LDAP schema
>> (is it posixUser?) and use it as hylafax uid? Of course it will not be
>> usable via PAM, but it could be used when hylafax+ directly access LDAP.
>>
>
> Yes, this is certainly possible, but I think it requires code development
> work. And in my way of thinking if someone is going to do some development
> work for this then that could be best-spent implementing a feature that
> works for all authentication methods (both PAM and LDAP). So that's how I'd
> spend *my* time trying to resolve it rather than developing something
> specific to LDAP.
PAM is "authentication only". So, on systems that use LDAP for system
users, etc, you always have to couple libpam-ldap and libnss-ldap.
PAM provides the "authentication" half, and then NSS provided all the
"name services" like unix user/group.
Where this get's "messy" is that PAM has service-based configuration
options, but NSS is only "global". So if we wanted to get HylaFAX to
retrieve uid information in the "PAM" model, after it authenticates,
it would call getpwname(the_user). The problem is that PAM allows
the "hylafax" service to have it's own config separate from everything
else (i.e. not common-auth, etc), but NSS doesn't.
So if we don't want to require the *system* to use LDAP for NSS, we're
going to have to go directly to "backend direct" like LDAP. Of
course, that means we loose the ability to plug into anything else
easily (like databases, pwdfile, etc). That means moving from runtime
flexibility, to compile-time selection of what to include. If we want
to go that way, we really should go to a "loadable module" type
interface, so that packagers don't have to force HylaFAX to depend on
everything (like all of ldap, libmysql, libpq, and whatever type of
authentication mechanism we decide to build in directly).
a.
Giuseppe Sacco
[...]
> PAM is "authentication only". So, on systems that use LDAP for system
> users, etc, you always have to couple libpam-ldap and libnss-ldap.
>
> PAM provides the "authentication" half, and then NSS provided all the
> "name services" like unix user/group.
Is there any other mechanism that provide both authentication and "name
services", or authentication and "identities"?
> So if we don't want to require the *system* to use LDAP for NSS, we're
> going to have to go directly to "backend direct" like LDAP. Of
> course, that means we loose the ability to plug into anything else
> easily (like databases, pwdfile, etc). That means moving from runtime
> flexibility, to compile-time selection of what to include. If we want
> to go that way, we really should go to a "loadable module" type
> interface, so that packagers don't have to force HylaFAX to depend on
> everything (like all of ldap, libmysql, libpq, and whatever type of
> authentication mechanism we decide to build in directly).
Is there any alread yavailable framework for this? Would SASL be a good
choice?
Bye,
Giuseppe
Joshua Kinard
But, from what I can recall from memory, the LDAP code is really simple. It basically tests for availability of the LDAP server, tests that it can access the directory, and tests the user's membership to see if it's in an allowed group to send a fax. Changing that shouldn't take too much effort, including the "groupMembership" string.
There's a lot of room for improvement, as the original patch was one I scrounged off of Google and updated to fit with the then-current release of HylaFax (which I think was 5.2.2).
HTH,
--J
________________________________
From: Lee Howard [fax...@howardsilvan.com]
Sent: Friday, December 10, 2010 11:00 AM
To: Giuseppe Sacco; Joshua Kinard
Cc: hylafa...@hylafax.org
Subject: Re: [hylafax-users] PAM authentication and JobProtection
Giuseppe Sacco wrote:
> Hi Lee,
> thanks for your prompt reply.
>
> Il giorno gio, 09/12/2010 alle 21.14 -0800, Lee Howard ha scritto:
> [...]
>
>> Consequently for this to be resolved hfaxd would need to automatically
>> add entries to hosts.hfaxd (or some other database/table/file) which
>> could be used to assign unique uid/gid to each user, but which would not
>> replace or interfere with future authentications. So some development
>> would be required to enhance and expand hfaxd to do this.
>>
>
> Do you think a new attribute in ldap would help? I mean, it would be
> possibile to add a faxGroup attribute to the currently used LDAP schema
> (is it posixUser?) and use it as hylafax uid? Of course it will not be
> usable via PAM, but it could be used when hylafax+ directly access LDAP.
>
Yes, this is certainly possible, but I think it requires code
development work. And in my way of thinking if someone is going to do
some development work for this then that could be best-spent
implementing a feature that works for all authentication methods (both
PAM and LDAP). So that's how I'd spend *my* time trying to resolve it
rather than developing something specific to LDAP.
I've added Joshua Kinard, the HylaFAX+ LDAP contributor, to this e-mail.
Giuseppe Sacco
I am willing to write and test all required source code in order to have
hylafax integrated with ldap (at least) and having all information we
already have from hosts.hfaxd: username, password, uid, (adminpassword).
I may create a patch against hylafax+ since it already connect to LDAP,
but I wish to have some suggestion on how to integrate it with hylafax
too.
Giuseppe Dia
Today the hylafax server I put up with those USB modems failed.
The line just rang free, but no fax was received and you could not see any
activity in syslog.
Restarting Hylafax solved the problem immediately.
Hylafax is 6.0.4-10ubuntu1 on an ubuntu i686 10.10 Linux
2.6.35-22-generic-pae #35-Ubuntu SMP
I looked at the logs but there's really nothing abnormal in them.
I enabled verbosity for all three modems, waiting for the next occurrence.
Is this any known issue? This a sample config.tty from one of them. The
modems are AtlantisLand (Conexant chip) USB modems using the ACM driver.
Any idea? No warning mails about modems wegded, I use to receive them if I
unplug one of the modems without stopping hylafax, so the warning system
should be ok.
Thanks,
GD
A sample config file
**************************************
CountryCode: 39
AreaCode: 0****
FAXNumber: +39****
LongDistancePrefix: 0
InternationalPrefix: 039
DialStringRules: etc/dialrules
ServerTracing: 1
SessionTracing: 11
RecvFileMode: 0600
LogFileMode: 0600
DeviceMode: 0600
RingsBeforeAnswer: 1
SpeakerVolume: off
GettyArgs: "-h %l dx_%s"
LocalIdentifier: Fax*****************
TagLineFont: etc/lutRS18.pcf
TagLineFormat: "From %%l|%c|Page %%P of %%T"
MaxRecvPages: 25
ModemType: Class1.0 # use this to supply a hint
ModemRate: 19200 # rate for DCE-DTE communication
ModemFlowControl: rtscts # default
ModemNoFlowCmd: AT&K0 # setup no flow control
ModemHardFlowCmd: AT&K3 # setup hardware flow control
ModemSoftFlowCmd: AT&K4 # setup software flow control
ModemSetupDTRCmd: AT&D2 # setup so DTR drop resets modem
ModemSetupDCDCmd: AT&C1 # setup so DCD reflects carrier (or
not)
Class1AdaptRecvCmd: AT+FAR=1 # reports carrier detection
mismatches
ServerTracing: 0xFFF #1
SessionTracing: 0xFFF #1
Lee Howard
> Today the hylafax server I put up with those USB modems failed.
> The line just rang free, but no fax was received and you could not see any
> activity in syslog.
> Restarting Hylafax solved the problem immediately.
>
Were the faxgettys running?
> Hylafax is 6.0.4-10ubuntu1 on an ubuntu i686 10.10 Linux
> 2.6.35-22-generic-pae #35-Ubuntu SMP
> I looked at the logs but there's really nothing abnormal in them.
> I enabled verbosity for all three modems, waiting for the next occurrence.
> Is this any known issue? This a sample config.tty from one of them. The
> modems are AtlantisLand (Conexant chip) USB modems using the ACM driver.
> Any idea? No warning mails about modems wegded, I use to receive them if I
> unplug one of the modems without stopping hylafax, so the warning system
> should be ok.
The only thing I can think of is that something happened to the modems
such as a power-cycle/reset that occurred unknown to HylaFAX/faxgetty.
Thus the modems ended up in an uninitialized state, and thus they
weren't operating as expected.
HylaFAX+ (http://hylafax.sourceforge.net) has a feature called
"PollLockPokeModem" which can be set to "true" which will cause faxgetty
to routinely check the modem to ensure that it's present and
responsive. Hopefully if the modems are reset this will faxgetty to
detect the problem and reset the modem automatically.
Thanks,
Lee.
Giuseppe Dia
thanks for the prompt answer.
The modems are usb and usb powered, I expect no power cycling should occur
without affecting the server itself (the server itself has an UPS).
Moreover I enabled the feature as well as the debugging, so next time I will
have more information.
I don't know if the faxgettys were running as I had to restart hylafax right
away, but I will look into it next time it happens (I hope I doesn't,
anyway).
Hope it's not a 'feature' of these cheap usb stuff.
Thanks,
G.
-----Messaggio originale-----
Da: hylafax-us...@hylafax.org
[mailto:hylafax-us...@hylafax.org] Per conto di Lee Howard
Inviato: giovedì 16 dicembre 2010 7.07
A: Giuseppe Dia
Cc: hylafa...@hylafax.org
Oggetto: Re: [hylafax-users] Hylafax Freeze with no error or warning
John Hudak
to 500 ma can be provided (I think the minimum specified is 200 ma, but I
have to double check that and the spec is not at my fingertips at the
moment). Over the past few years, board manufactures have tended to 'skimp'
on current capabilities on the USB ports. This is a general statement, many
mfg do not put the current specs for the USB ports in their board manuals.
To eliminate USB power as an potential problem, one can use an externally
powered USB port expander or, use a USB cable that has a second parallel USB
plug to provide additional power.
Good luck,
John
On Thu, Dec 16, 2010 at 5:56 AM, Giuseppe Dia <giusep...@bamado.com>wrote:
> Hi Lee,
> thanks for the prompt answer.
> The modems are usb and usb powered, I expect no power cycling should occur
> without affecting the server itself (the server itself has an UPS).
> Moreover I enabled the feature as well as the debugging, so next time I
> will
> have more information.
> I don't know if the faxgettys were running as I had to restart hylafax
> right
> away, but I will look into it next time it happens (I hope I doesn't,
> anyway).
> Hope it's not a 'feature' of these cheap usb stuff.
> Thanks,
>
> G.
>
> -----Messaggio originale-----
> Da: hylafax-us...@hylafax.org
> [mailto:hylafax-us...@hylafax.org] Per conto di Lee Howard
> Inviato: giovedì 16 dicembre 2010 7.07
> A: Giuseppe Dia
> Cc: hylafa...@hylafax.org
> Oggetto: Re: [hylafax-users] Hylafax Freeze with no error or warning
>
Giuseppe Dia
I had another occurrence of the freeze.
This time I followed Lee advice, and looked for faxgettys. They were NOT
running.
After restarting hylafax everything is nice again and the faxgettys are
there again.
I cannot find anything in the log. I noticed it just happens during the
weekend, so I suspect there's something related with inactivity.
Is there any reason why inactivity or some weird incoming fax could mess
with faxgettys? Aren't they supposed to spawn again in the event of a
problem?
Now I expect it running for a week and then die in the WE for some strange
reason.
P.s: "PollLockPokeModem: true" is on every modemd config.
Bye, and thanks,
Da: hylafax-us...@hylafax.org
[mailto:hylafax-us...@hylafax.org] Per conto di Lee Howard
Inviato: giovedì 16 dicembre 2010 7.07
A: Giuseppe Dia
Cc: hylafa...@hylafax.org
Oggetto: Re: [hylafax-users] Hylafax Freeze with no error or warning
Giuseppe Dia wrote:
> Today the hylafax server I put up with those USB modems failed.
> The line just rang free, but no fax was received and you could not see any
> activity in syslog.
> Restarting Hylafax solved the problem immediately.
>
Were the faxgettys running?
____________________ HylaFAX(tm) Users Mailing List _______________________
David Forrest
> Hi all,
> I had another occurrence of the freeze.
> This time I followed Lee advice, and looked for faxgettys. They were NOT
> running.
> After restarting hylafax everything is nice again and the faxgettys are
> there again.
> I cannot find anything in the log. I noticed it just happens during the
> weekend, so I suspect there's something related with inactivity.
> Is there any reason why inactivity or some weird incoming fax could mess
> with faxgettys? Aren't they supposed to spawn again in the event of a
> problem?
> Now I expect it running for a week and then die in the WE for some strange
> reason.
>
> P.s: "PollLockPokeModem: true" is on every modemd config.
>
> Bye, and thanks,
Without knowing more about your system, I can't advise on how to set it up
to respawn. But you should be able to check easily if a faxgetty is
running by using a: pgrep faxgetty
You'll get a pid if it is or nothing if not.
This test can be put in a root crontab to restart it automatically like
this example from my root crontab:
* * * * * /usr/bin/pgrep faxgetty >/dev/null || /usr/local/sbin/faxgetty ttyS1
This checks every minute for a pid of a running faxgetty and starts one if
missing.
Your mileage may vary though.
Dave
--
David Forrest
St. Louis, Missouri
Lee Howard
> This time I followed Lee advice, and looked for faxgettys. They were NOT
> running.
So keep looking at the logs, etc. (In particular, look at your syslog,
/var/log/messages.) WHY were they not running? What stopped them? Did
the modems "wedge"?
Thanks,
Lee.
Giuseppe Dia
Giuseppe Dia wrote:
> This time I followed Lee advice, and looked for faxgettys. They were NOT
> running.
So keep looking at the logs, etc. (In particular, look at your syslog,
/var/log/messages.) WHY were they not running? What stopped them? Did
the modems "wedge"?
Hi all,
maybe I found something interesting about the freeze issue:
Dec 22 10:48:07 xxxxxx-hylafax1 FaxGetty[32044]: RECV FAX (000000238): from
*********, page 2 in 0:01:30, INF, 3.85 line/mm, 2-D MR, 14400 bit/s
Dec 22 10:48:07 xxxxxx-hylafax1 FaxGetty[32045]: <-- [3:AT\r]
Dec 22 10:48:07 xxxxxx-hylafax1 FaxGetty[32045]: --> [2:OK]
Dec 22 10:48:37 xxxxxx-hylafax1 FaxGetty[32045]: <-- [3:AT\r]
Dec 22 10:48:37 xxxxxx-hylafax1 FaxGetty[32045]: --> [2:OK]
Dec 22 10:49:07 xxxxxx-hylafax1 FaxGetty[32045]: <-- [3:AT\r]
Dec 22 10:49:07 xxxxxx-hylafax1 FaxGetty[32045]: --> [2:OK]
Dec 22 10:49:37 xxxxxx-hylafax1 FaxGetty[32045]: <-- [3:AT\r]
Dec 22 10:49:37 xxxxxx-hylafax1 FaxGetty[32045]: --> [2:OK]
Dec 22 10:49:38 xxxxxx-hylafax1 kernel: [1271819.832059] faxgetty[32044]:
segfault at 30320a46 ip 0805b6a3 sp bfa26090 error 4 in
faxgetty[8048000+72000]
Seems a known bug here:
https://bugs.launchpad.net/ubuntu/+source/hylafax/+bug/600219
I think I should stick in a watchdog cron script, as David Forrest
suggested. My mileage will vary indeed as I'm forced to restart hylafax
altogheter rather than spawning new faxgetty, because having many of them I
don't really know which one fails (I must say they all fail, to be fair).
What's your take on this?
Bye and thanks for the help so far.
GD
Aidan Van Dyk
> Seems a known bug here:
> https://bugs.launchpad.net/ubuntu/+source/hylafax/+bug/600219
> I think I should stick in a watchdog cron script, as David Forrest
> suggested. My mileage will vary indeed as I'm forced to restart hylafax
> altogheter rather than spawning new faxgetty, because having many of them I
> don't really know which one fails (I must say they all fail, to be fair).
> What's your take on this?
> Bye and thanks for the help so far.
If that's the same bug, and you can reproduce and have basic skills at
GDB, or linux, we'ld love to get a copy of a core file, or back trace
or anything really on the crashing faxgetty.
None of the "backtraces" or dump in that ticket are actually faxgetty,
they are all lots of various children of faxgetty (like tiff2pdf,
called from faxrcvd, during a non-crashing faxgetty run). And both
reported it "fixed" after upgrading kernel and replacing faulty
hardware...
a.
Giuseppe Dia
[mailto:hylafax-us...@hylafax.org] Per conto di Aidan Van Dyk
Inviato: giovedì 23 dicembre 2010 15.13
A: Giuseppe Dia
Cc: Lee Howard; hylafa...@hylafax.org
Oggetto: Re: [hylafax-users] R: R: Hylafax Freeze with no error or warning
On Thu, Dec 23, 2010 at 3:54 AM, Giuseppe Dia <giusep...@bamado.com>
wrote:
> Seems a known bug here:
> https://bugs.launchpad.net/ubuntu/+source/hylafax/+bug/600219
> I think I should stick in a watchdog cron script, as David Forrest
> suggested. My mileage will vary indeed as I'm forced to restart hylafax
> altogheter rather than spawning new faxgetty, because having many of them
I
> don't really know which one fails (I must say they all fail, to be fair).
> What's your take on this?
> Bye and thanks for the help so far.
>If that's the same bug, and you can reproduce and have basic skills at
>GDB, or linux, we'ld love to get a copy of a core file, or back trace
>or anything really on the crashing faxgetty.
Thanks for your answer. If it does it again I will provide you with the core
files. At the moment I had to solve things quickly for obvious reasons and I
had no more crashes.
>None of the "backtraces" or dump in that ticket are actually faxgetty,
>they are all lots of various children of faxgetty (like tiff2pdf,
This remind me it stated after I enabled PDF as filetype.
>called from faxrcvd, during a non-crashing faxgetty run). And both
>reported it "fixed" after upgrading kernel and replacing faulty
>hardware...
I followed the bugreport advice of upgrading the kernel from
linux-image-2.6.35-22-generic-pae on x86 (last one on ubuntu 10.10).
This only made things worse, with faxgettys started dying after successful
reception of faxes minute by minute. Before the upgrade they use to die
once in a week. I then followed the other advice in the bugreport: I
disabled apparmor and setup a cron job to check for the faxgetty every
minute or so and send a warning when one of the faxgetty (say faxgetty -D
ttyACM0) would die.
So far I'm seeing all of them, no warning, and everything is just fine. Too
soon to say if this solved the problem, but at least they stopped dying
minute by minute. I'll keep you posted with the result and send you the core
files, if it happens to die again.
I will also try taking out Filetype: pdf.
Thanks,
GD
Giuseppe Sacco
Il giorno lun, 27/12/2010 alle 16.54 +0100, Giuseppe dia ha scritto:
> The situation gets worse and worse. I now disabled the filetype=pdf;; entry, to
> ensure it was not a tif2pdf problem. But the problem still occurrs.
> I'm setting
> uucp soft core 100000
> uucp hard core 100000
> into limits.conf to have a look at the core files.
> have you got an idea of where I will find the core files?
core files are dumped on the current directory of the killed process.
For hylafax daemons, the directory should be /var/spool/hylafax.
Bye,
Giuseppe