Re: getpwnam with md5 encrypted passwds
Clifton Royston wrote: > If you will need to do authentication after your program drops > privileges, your best course is probably to go through PAM, to install > a separate daemon which implements a PAM-supported protocol and which > runs with privileges, and then to enable that protocol as a PAM > authentication method for your application. [ ... RADIUS example with LDAP mention ... ] Sounds like a good approach, though I'll point out that had you tried LDP, you would have been hard-put to use LDAP as a proxy protocol to another authentication base (a PAM backend for an LDAP server, while not quite impossible, would be very hard). How did you avoid the recursion problem of the RADIUS server trying to authenticate via pam_radius to the RADIUS server tyring to authenticate ... -- Terry? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getpwnam with md5 encrypted passwds
Peter Pentchev wrote: > On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote: > > Looks interesting ... is this method also usable, when i dropped my privs ? > > I think Terry meant pam_authenticate() (not pan), but to answer your > question: no, when you drop your privileges, you do not have access to > at least the system's password database (/etc/spwd.db, generated from > /etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any > consolation, getpwnam() won't return a password field when you have > dropped root privileges either. Peter is correct on both counts. If I had not sen his reply first, I would have made the same reply. You cannot crypt something you cannot read. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS Flags Oddity
Kris Kirby wrote: > FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. You've > got to shell in locally to the machine to move the schg flags; ls -lao > doesn't report them over NFS, but does list them locally. Non-local flags are not defined, so they are not permitted to be exported over NFS. You'll find the same thing with the number of bits in major and minor number, etc.. For a long time (until Julian added the first devfs to FreeBSD), it was not possible to NFS-boot a FreeBSD box off of e.g. an Alpha running TRU64 UNIX, for example. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: TWE driver IOCTL's]
Eduard Martinescu writes: > Tried this on current, but no responses...maybe some one here has some ideas? > > Hello, > > I looking to extend the smartmontools support > (/usr/ports/sysutils/smartmontools) to include support for drives behind > a TWE device. > > I looked at the source for the TWE driver, and it seems to support what > I neednot sure yet, as the linux version use the ATA Passthru > IOCTL. At any rate, there does not appear to be any twe.h include files > installed into /usr/include anywhere for my program to be able to pick > the correct definitions. Is this just an oversight? Or did I miss > something? > Looks like an oversight. It seems that /sys/dev/twe/tweio.h should get installed into /usr/include/sys. Maybe /sys/dev/twe/twereg.h too, since that's where TWE_Command is defined, although not everything in there seems like it should be visible to the user. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ahd driver & Adaptec 39320D Ultra320 SCSI adapter
Hi, I mailed to fbsd-questions about a weird problem i was experiencing with RAID10 on vinum, with 4 SCSI disks connected to an Adaptec 39320D U320 SCSI adapter, and stated that it had boot problems, but they seemed to occur only at boot, not during usage. I was wrong. The card is unstable in FreeBSD 4.9-release. Not only does the SCSI interface timeout on occasion, vinum also seems to crash the entire system with a kernel panic. I googled on "pci error interrupt" "card was paused", but no helpful results turned up. Is anyone aware of this problem? Who should I contact to report this, or does anyone know what the solution for this problem is? I'd really like to get it fixed. Let me know if you need more information regarding this matter. Below are some relevant parts from dmesg, during boot: | ahd0: port 0x7000-0x70ff,0x7400-0x74ff mem 0xfc20-0xfc201fff irq 10 at device 1.0 on pci3 | aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs | ahd1: port 0x7800-0x78ff,0x7c00-0x7cff mem 0xfc202000-0xfc203fff irq 10 at device 1.1 on pci3 | aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs [ .. later on in the boot process .. ] | ahd1: PCI error Interrupt | >> Dump Card State Begins < | ahd1: Dumping Card State at program address 0x94 Mode 0x22 | Card was paused | HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] | DFFSTAT[0x30]:(CURRFIFO_0|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) | SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) | SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) | SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x80]:(INTVEC1DSL) | SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) | SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) | LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] | LQOSTAT1[0x0] LQOSTAT2[0x0] | | SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0x CURRSCB 0x0 NEXTSCB 0x0 | qinstart = 0 qinfifonext = 0 | QINFIFO: | WAITING_TID_QUEUES: | Pending list: | Total 0 | Kernel Free SCB list: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 | Sequencer Complete DMA-inprog list: | Sequencer Complete list: | Sequencer DMA-Up and Complete list: | | ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 | SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) | SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) | SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] | SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 | HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) | ahd1: FIFO1 Free, LONGJMP == 0x80ff, SCB 0x0 | SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) | SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) | SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] | SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 | HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) | LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 | ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 | ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 | | SIMODE0[0x6c]:(ENOVERRUN|ENIOERR|ENSELDI|ENSELDO) | CCSCBCTL[0x0] | ahd1: REG0 == 0x3533, SINDEX = 0x33, DINDEX = 0x0 | ahd1: SCBPTR == 0x0, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0 | CDB 0 0 0 0 0 0 | STACK: 0x1 0x8 0x7 0x6 0x5 0x4 0x3 0x29 | > | ahd1: Signaled Target Abort Thanks in advance, Sander. -- | A box withouth hinges, key, or lid, yet golden treasure inside is hid. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd smp -> linux up
On Wed, 26 Nov 2003, Anthony Schneider wrote: > sadly, all ktrace shows is ktrace launching vmware (from 'ktrace > vmware', shows sh reading and executing, and then ends with the vmware > fork). > > is there a special way to ktrace linux binaries that i'm not aware of? ktrace should work fine, but you need to make sure you use the linux_kdump port so that the system call trace is interpreted correctly when converted to text. As DES points out, make sure you have the right flags to the ktrace command so tracing is inheritted across fork and exec. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories > > -Anthony. > > On Tue, Nov 25, 2003 at 07:32:35PM +0100, Dag-Erling Smørgrav wrote: > > Anthony Schneider <[EMAIL PROTECTED]> writes: > > > is there a way to have linux emulation report that its kernel is running > > > on a UP system even though the freebsd box it's running on is SMP? i > > > would like to get vmware running on my smp -current box, but vmmon_smp.ko > > > is "broken", and with vmmon_up.ko loaded i get a message about needing to > > > be running on an smp linux kernel version 2.0 (2.2) or higher, even though > > > linux emulation reports a 2.4 kernel. > > > > It would be interesting to know exactly what it needs that we don't > > provide. I suspect it's something really trivial... do you see any > > messages in syslog about unimplemented syscalls? Could you get a > > ktrace or something? > > > > DES > > -- > > Dag-Erling Smørgrav - [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getpwnam with md5 encrypted passwds
On Wed, Nov 26, 2003 at 11:10:01PM -0800, Terry Lambert wrote: > Clifton Royston wrote: > > If you will need to do authentication after your program drops > > privileges, your best course is probably to go through PAM, to install > > a separate daemon which implements a PAM-supported protocol and which > > runs with privileges, and then to enable that protocol as a PAM > > authentication method for your application. > > [ ... RADIUS example with LDAP mention ... ] > > Sounds like a good approach, though I'll point out that had > you tried LDP, you would have been hard-put to use LDAP as a > proxy protocol to another authentication base (a PAM backend > for an LDAP server, while not quite impossible, would be very > hard). Glad I went with my gut feeling rather than wasting a lot of time looking into it then... > How did you avoid the recursion problem of the RADIUS server > trying to authenticate via pam_radius to the RADIUS server > tyring to authenticate ... That is avoided two ways, either of which would do to prevent the deadly recursion. First the RADIUS server (FreeRadius) is currently set up to implement "Unix auth" directly against spwd.db, not via PAM. Second, it's not enabled as the default PAM authentication method for all applications, only for some specific application tokens. We have an intention to add to the application auth against some separate non-password db files, followed by OTP support down the road. Hopefully as it uses PAM both should now be relatively easy. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
question about _exit() function
Hi, is the _exit() function safe for a thread ? my program use vfork() and then execve in a thread context. The documentation mentions that the process has to call _exit() in case of failure. But this _exit() is really safe for the parent thread ? Thanks in advance for the reply. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question about _exit() function
and I use freebsd v4.8. On Thu, 27 Nov 2003, rmkml wrote: > Date: Thu, 27 Nov 2003 20:20:04 +0100 (CET) > From: rmkml <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: question about _exit() function > > Hi, > > is the _exit() function safe for a thread ? > my program use vfork() and then execve in a thread context. > The documentation mentions that the process has to call _exit() in case > of failure. > But this _exit() is really safe for the parent thread ? > > Thanks in advance for the reply. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
