On Thu, 01 Feb 2001, juergen.braukmann@ruhr-west.de wrote:
dproc@dol.net wrote:
Is it ok to copy this mail to the list?
Yes. I don't mind. ;-)
On Wed, 31 Jan 2001, juergen.braukmann@ruhr-west.de wrote:
Spontanously, I would have given the same answer than that kind soul. Btw., rc.config uses a variable that tells wether a2ps or -I think enscript- is used. I could print, but nothing in ascii mode. I've been searching a week. (/etc/rc.config is sourced by apsfilter. *CRAP*!)
My rc.config doesn't have such a variable, and is not sourced by apsfilter. Maybe you have a different version of apsfilter - mine is called S.u.S.E.-1.6 and comes from the 6.3 distro.
yes. I've been a bit quick with that. This "feature" appeared in 7.0
(rc.config is sourced by /sbin/init.d/lpd from plp on my system, but as init runs as root that works fine.)
yes. that is OK.
To use the debug mode is a good idea. The next thing I'd check are permissions on these commands. I do not think head, tr, tail, grep and cut are harmful, but... Check also the path permissions to these commands. Keep in mind that running SuSEconfig will reset these permissions, you need to set them in /erc/permissions.local.
My permission checks follow:
chmod g+ -v / mode of / retained as 0755 (rwxr-xr-x) chmod g+ -v /usr mode of /usr retained as 0765 (rwxrw-r-x) chmod g+ -v /usr/bin mode of /usr/bin retained as 0755 (rwxr-xr-x) chmod + -v /usr/bin/head mode of /usr/bin/head retained as 0755 (rwxr-xr-x)
These look ok to me.
I then rewrote apsfilter a little. I substituted the full path /usr/bin/head for head. Now the log message changes to
/var/lib/apsfilter/bin/stc600p.upp-letter-auto-color-720: /usr/bin/head: Permission denied
I would have tried that too.
Finally I looked at
chmod + -v apsfilter mode of apsfilter retained as 0755 (rwxr-xr-x)
I think the change from 'command not found' to 'Permission denied' tells me something, but I am not sure what.
yes. It reminds me of a mounted CD with the -heck- user ? mount option that includes the "noexec" option. With other words, also you see the exec flag, excecuting is not permitted. That would mean you won't be able to execute these commands from the shell too. Beiing under /usr it would hit the entire partition as well as the user root. With that my thought is a dead end too. ;-(
In the end, I believe it's something stupid easy, but I am at my wit's end.
less /etc/fstab /dev/hda6 / ext2 defaults 1 1 /dev/hda7 /usr ext2 defaults 1 2
This is what root looks like: drwxr-xr-x 21 root root 1024 Aug 4 2000 . drwxr-xr-x 21 root root 1024 Aug 4 2000 .. drwxr-xr-x 3 root root 1024 Jan 31 1999 .kde -rw-r--r-- 1 root root 135 Mar 27 1999 DIRLIST drwxr-xr-x 2 root root 1024 Jan 31 1999 S.u.S.E. -rw-r--r-- 1 root root 82019 May 16 1999 System.map -rw-r--r-- 1 root root 128530 May 16 1999 System.map.old -rw-r--r-- 1 root root 128530 Jan 30 1999 System.old drwxr-xr-x 2 root root 1024 Aug 5 2000 bin drwxr-xr-x 3 root root 1024 Aug 6 10:47 boot drwxr-xr-x 2 root root 1024 Apr 2 2000 cdrom lrwxrwxrwx 1 root root 8 Apr 30 2000 data -> usr/data drwxr-xr-x 6 root root 30720 Jan 31 17:34 dev drwxr-xr-x 34 root root 8192 Feb 1 00:00 etc drwxr-xr-x 2 root root 1024 Apr 2 2000 floppy lrwxrwxrwx 1 root root 10 Apr 1 2000 home -> /data/home drwxr-xr-x 5 root root 2048 Jan 27 08:43 lib drwxr-xr-x 2 root root 12288 Mar 27 2000 lost+found drwxr-xr-x 12 root root 1024 Jun 24 2000 mnt lrwxrwxrwx 1 root root 7 Apr 30 2000 opt -> usr/opt dr-xr-xr-x 71 root root 0 Jan 28 14:12 proc drwx--x--x 18 root root 2048 Jan 31 22:43 root drwxr-xr-x 5 root root 3072 Jan 22 21:18 sbin lrwxrwxrwx 1 root root 9 Apr 1 2000 src -> /data/src drwxr-xr-x 3 root root 1024 Sep 8 1998 suse drwxrwxrwt 32 root root 27648 Feb 1 21:05 tmp drwxrw-r-x 31 root root 1024 Aug 6 15:44 usr drwxr-xr-x 19 root root 1024 Sep 10 23:07 var -rw-r--r-- 1 root root 386579 May 16 1999 vmlinuz -rw-r--r-- 1 root root 386577 May 16 1999 vmlinuz.old drwxr-xr-x 2 root root 1024 Jan 30 1999 windows just for kicks,
df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda6 202182 161346 30396 84% / /dev/hda7 4307040 2718844 1365296 67% /usr /dev/hda2 7525 3431 3693 48% /boot /dev/hda4 2007840 16896 1990944 1% /mnt/fat
and finally, swanage:~ # rpm --verify gs_both swanage:~ # rpm --verify aps S.5....T /var/lib/apsfilter/apsfilter swanage:~ # rpm --verify plp S.5....T c /etc/printcap swanage:~ # and finally, I gave lp a login bash shell, did # su -l lp and tried, lp@swanage:~ > which head /usr/bin/head lp@swanage:~ > head car car ball cat ball cat lp@swanage:~ > grep tree car fish tree tree ball lp@swanage:~ > /var/lib/apsfilter/apsfilter ... and the script ran without stupid errors interactively. lp@swanage:~ > /usr/lib/apsfilter/bin/apsfilter ... and again ok I know there are subtle differences in the environment+privileges of a script called from a daemon versus one called from a prompt by 'su -l lp' but I haven't found documented what they are or how they are influenced. Pointers ?? I am so embarrassed to be doing this, I am glad I used a pseudonym. Yours, dproc