[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Insufficient benzed.... err caffiene
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
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 :
>> that says:
>> pass in on wi0 from $user_ip to any keep state
>> and the test user has:
>> 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
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.