Hello Andreas, before answering I want to say that I have overtaken capi4hylafax a short time before the freeze of wheezy and since them I only try to fix all RC relevant bugs. With the same intention I worked on hylafax together with the maintainer.
Andreas Beckmann wrote on 2013-02-07 00:02: > A short review on capi4hylafax ... Thank you! > capi4hylafax.prerm looks borked: having the #DEBHELPER# token inside the > else branch looks wrong. I have seen them, too. It seems, that the "normal" code of #DEBHELPER# is needed if the special code for versions before 01.03.00.99.svn.300-14. I think that could be ok (but I haven't tested this). > capi4hylafax.init: > * shouldn't the "Please edit the file /etc/hylafax/config.faxCAPI"... > message be restricted to starting the daemon? Why repeat it for stop etc? Yes! I big problem. And this string should be shorter (one line). > * copy_slash_etc is run unconditionally - on start, on stop, regardless > of the run_capi4hylafax setting. Shouldn't it be sufficent to do this on > start/restart/reload? Yes, that is true - I had the same mind. > But back to the original problem ... *why* does /var/spool/hylafax need > to be owned by uucp:uucp? I think, that is a long story. I only know the problems between hylafax and capi4hylafax, which show that capi4hylafax must work similar as hylafax to use the same directory (var/spool/hylafax). Here I will point you to the special kind how hylafax uses this spool directory (see inside post/pre scripts of hylafax): after some tests hylafax make a "mount --bind" between /etc/hylafax and /var/spool/etc. > Isn't it generally problematic to have root write to a non-root-owned > directory (copy_slash_etc in capi4hylafax.init and the equivalent > functionality in hylafax.init) - think about symlinks created by an > unprivileged process with write permissions in that directory ... > similarly the maintainer scripts must be careful on remove/purge when > acting on this unprivileged directory. Do I understand you right: Do you think it is better to set chmod 750 or similar to /var/spool/hylafax (and its subdirectories)? > As there is bin/ and etc/ this looks like some daemon should be running > jailed there ... but I didn't see anything in the initscripts. The only > candidate I have seen is $SPOOLDIR/FIFO - but if uucp:uucp is needed to > create that FIFO, wouldn't (as root) mkfifo $SPOOLDIR/FIFO ; chown > uucp:uucp $SPOOLDIR/FIFO be sufficient? Perphaps the maintainer of hylafax (Giuseppe Sacco) knows an answer. > Looking at hylafax-server, it ships a whole bunch of empty directories > owned by uucp:uucp in /var/spool/hylafax ... that is OK. Only shipping > non-empty directories owned by non-root is problematic: > /var/spool/hylafax/ > /var/spool/hylafax/config/ which comes with a bunch of files How should be the way for this config directory? Inside this dir. are some hardware specific configurations for modems. > uucp:uucp can modify anything in there ... The login for uucp is disabled. I have tested 'chmod o-rx' inside /var/spool/hylafax/. Then no fax goes out anymore because of missing some read permissions, escpecially for ./etc and ./bin. (I have made some tests with the result: all directories could better have group uucp and permissions 0750). > PS: don't try this on a real system !!!!! (added some X intentionally) > # apt-get install hylafax-server > # su uucp -c "rm -rf /etc" # does not work, of course > # su uuXcp -c 'mXv /var/spoXol/hylafax/bin /var/spool/hXylafax/b!n' > # su uXucp -c 'lXn -s /eXtc /vXar/spool/hylXafax/bin' > # apt-get install --reinstall hylafax-server > # find /etc > find: `/etc': No such file or directory This seems really unsafely. Last question from me: Which point MUST be fixed before release of wheezy? --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
