On Fri, 08 Apr 2005 07:01:56 -0600, j knight wrote: >Rod.. Whitworth wrote: > >> pf.conf with: >> anchor "/authpf/*" > >With a leading slash? I'm not sure if this would cause you problems or >not...
That's a "long day typo". I had it correctly done in the file. > >> placed just after a block rule that will be overthrown by : >> /etc/authpf/authpf.rules >> that says: >> pass in on wi0 from $user_ip to any keep state >> and the test user has: >> /usr/sbin/authpf >> as its shell. > >PLEEEEEEASE don't paraphrase your pf.conf/authpf.rules. This is really >getting annoying. People asking for help, even complaining when they >don't get it, but they're unwilling to paste complete, unedited config >files, commands being run, log messages, etc. > I know that is usually the case but like all rules there are exceptions. In this case I should have stressed that the rules were identical on the working and non working machines. Putting a (very) long file full of complex nat &rdr rules ahead of yards of filter rules would have added noise to the important bit which was the log entry. But don't blow a fuse - read on: >> On the target /var/log/messages says: >> Apr 8 19:46:20 puffy -authpf: cannot open packet filter device >> (Permission denied) > >Wow. A log message! :P > >Probably want to quickly verify the permissions on these files: > >jknight:~% ls -l /dev/pf /usr/sbin/authpf >crw------- 1 root wheel 73, 0 Dec 22 20:08 /dev/pf >-r-sr-sr-x 1 root authpf 18068 Dec 9 18:01 /usr/sbin/authpf >.joel > And THAT did it. I had checked the perms on /dev/pf because it was obviously what couldn't be opened but, dozy me, did NOT check that authpf had suid/sgid on and for some bizarre reason it did not. Also it was owned by root:wheel. I don't know how but that box had all of /usr/bin and /usr/sbin files owned by root/wheel and all suid/sgid perms were missing. I pkg_added rsync which was on the LabRat and rsynced both of those dirs and I'll carefully check the rest later. Thanks for spotting the thing I missed and might not have thought of for quite a while anyway - I don't mess around with permissions on system supplied commands unless told to by [EMAIL PROTECTED]> >From the land "down under": Australia. Do we look <umop apisdn> from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
