On Tue, 2005-06-07 at 03:40 -0700, Valery Reznic wrote:
>
> --- Marco Colombo <rpm-list@xxxxxxxxxx> wrote:
> > Two reasons. First, you may need those permissions
> > later when building
> > the package. It's very borderline, but think of a
> > file --w--w--w-. Or a
> Got it.
>
>
> > socket, which is more likely. You won't be able to
> > read it later at cpio
> > time. Second, you might not be able to set them
> > right at %install time,
> > think of setuid. Or a directory that should be 555
> > but you still want to
> setuid - you set any permission for file your are owne
> (in directory you are owned)
> directory with mode 555 - it may be created with any
> permission, files copied in and then 'chmod 555'
>
> Valery
You're right, for setuid, you can usually set it (but how about /var/tmp
or /home partition mounted nosuid,nodev for extra security? Even more if
it's NFS mounted...) but it won't be retained on any following copy. I'm
not sure you can create a suid executable owned by you, list it as
%attr(root,-,-) in %files, and get it suid in the rpm. I've never tried
to actually. And I'd call that a really bad practice, it's much better
to put all the info in one place (%files) for readability.
And for other kind of permissions, sure you can do that but you have to
take care of it, at the right time. For sure you can't create a
directory with install -m 555 and then add files to it, unless you're
root. And fixing your %install script may be easy, patching a Makefile
not so. Unless I have a valid reason not to, I remove every attempt to
set ownership and permissions at %install time as a general rule.
There may be some valid reasons to set permissions at %install time in
particular cases, so the rule is not as strict as the ownership one
(setting ownership is usually for root only anyway).
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
