Re: chmod/chown -R - maybe an ITP
On Mon, 13 Dec 1999, Anthony Towns wrote:
>
>On Mon, Dec 13, 1999 at 03:37:14PM +0100, Russell Coker wrote:
>> On Mon, 13 Dec 1999, Daniel Burrows wrote:
>> >On Mon, Dec 13, 1999 at 03:19:36PM +0100, Russell Coker was heard to say:
>> >> [...] "recurse through this directory and change the ownership or
>> >> permissions of files owned by this user". [...]
>> >Can't you do this with find and xargs? Or are you looking for something more
>> >sophisticated?..
>> find and xargs is better but has race conditions. [...]
>
>I'm not sure you'll get one without race conditions at all (in userspace,
>anyway), but:
You can and I've already posted the pseudo code for it. That's why there are
fchown and fchmod system calls!
> find /home/foo -uid 105 -exec chown 4242.4242 {} \;
>
>probably has a fairly minimal window, and shouldn't result in *too*
>much overhead.
It still has a window and it has overhead.
The way you stretch the window is by making the machine busy at the time.
This is quite easy with cron jobs.
>One way of doing this correctly (as opposed to efficiently, say), might be
>to make a hardlink of each file you see, check the hardlink is owned by the
>right user, chown/chmod the hardlink, and remove the hardlink.
Or use fchmod after using fstat to check the permissions.
>(Another possibility, if chown supported giving away your own files (ie,
>if you could chown any file you owned to any other user), like at least
>some of the books I've read say it should, would be su'ing to each uid
>first, and running chown. Of course, chown doesn't support this, so...)
If chown does then it allows you to beat any quota system.
Also if chown does then once you (somehow) manage to get ownership of a
system file or program (you can make it run as a daemon listening on a high
port and offer a /bin/sh invocation to the first person to telnet in) you can
chown it back to root so that no-one will suspect.
OTOH if there was a chown that required that you have permissions of one of
the users and entered the password of the other one could be handy. EG If
you're working with someone you could lend them your terminal and they could
chown some of your files to them. However scp and sendfile fill most of the
need for this so there's probably no point.
--
The ultimate result is that some innovations that would truly benefit
consumers never occur for the sole reason that they do not coincide with
Microsoft's self-interest.
-- Judge Thomas Penfield Jackson, U.S. District Judge
Reply to: