bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

address@hidden: Re: cp as root and +s]


From: kutek
Subject: address@hidden: Re: cp as root and +s]
Date: Sun, 8 Jul 2001 08:42:32 -0400
User-agent: Mutt/1.2.5i

I thought the enclosed conversation would be of interest. prior to
contacting solar designer i did look at the fileutils (4.1) info for cp
and was unable to find the information he mentions. most users might not
pick up on this subtlety  and the results could be disastrous.


fractoid
--- Begin Message --- Subject: Re: cp as root and +s Date: Sun, 8 Jul 2001 04:42:09 +0400 User-agent: Mutt/1.2.5i
On Sat, Jul 07, 2001 at 07:08:38PM -0400, address@hidden wrote:

Hi,

> i'd like to ask your opinion. let's say i have a file (bin) which is suid a 
> non privileged user, which i copy to another file while i'm root.
> The new file is now SUID *ROOT*. a reputable linux kernel developer informs
> me that this is expected behavior for root, and i find this incredibly
> dangerous, and unexpected.

(This has nothing to do with the kernel, it's a property of cp.)

> Is this something that should be prevented in secure systems?

Yes, I think so.  This is really the expected behavior if you read the
texinfo documentation for GNU fileutils, but I agree that most people
wouldn't expect cp to leave the SUID and SGID bits when cp isn't told
to also preserve the file's ownership.

`-p'
`--preserve'
     Preserve the original files' owner, group, permissions, and
     timestamps.  In the absence of this option, each destination file
     is created with the permissions of the corresponding source file,
     minus the bits set in the umask. *Note File permissions::.

I think that cp without -p (and -a) should also not copy the three
bits not controllable with umask.

Feel free to forward this to <address@hidden> and please CC me
if you do so.

-- 
/sd

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]