Package: xorp Version: 1.6-3 Severity: minor Hello,
xorp's changelog.Debian.gz claims the ownership change of /etc/xorp
to xorp should permit users running 'xorpsh' to save their
configuration (xorp 1.6-1). This doesn't really work:
If you intend to allow users to create new files, permitting them to
save would require write-permissions by the xorp group for the
directory, they are not currently granted.
If you do not intend to allow users to create new files, save doesn't
really work either: After a fresh package install, /etc/xorp/config.boot
is owned by root and not writable by the xorp group. While this could
also be intentional, I don't believe it is, because after a package
upgrade /etc/xorp/config.boot is owned/grouped by xorp.
This is caused by the way the xorp package sets the directory- and
file-permissions: instead of shipping the permissions within the
package, they are changed preinst. Files are installed after preinst,
and hence get not modified. postinst would probably be a better place to
do such stuff - you also don't need to mkdir then.
Shipping permissions within the package would solve this issue for fresh
installs: in the rules file just chown/chmod the respective files in the
debian/ tree after dh_fixperms.
However, this approach does not alter the permissions of already
existing directories (Debian Policy, 10.9, [1]) and unchanged conffiles
(they are kept unchanged) on upgrades.
Btw.: `xorpsh# save foo' currently defaults to write to /foo. This can
be fixed by adding a small config snippet:
| rtrmgr {
| config-directory: "/etc/xorp"
| }
This way, `xorpsh# save foo' defaults to write to /etc/xorp/foo.
regards
Mario
--
The only thing to be scared of, son, is tomorrow.
I don't live for tomorrow. Never saw the fun in it.
-- Denny Crane, Boston Legal
signature.asc
Description: Digital signature
