Can"t chown() "my" files...

On a Linux server, a web page lets users enter items to an order
sheet. When they finish, (besides the mysql db updates) the order data
is emailed to the user as confirmation, a copy is emailed to the
fulfillment people, and two files are written for pickup by a third
party, in the third party's directory.

Because the files are owned by apache, the third party cannot delete
them, even when they are chmod'ed to 777. I tried to chown() the files
to the third party's user, but no go.

Re: Can"t chown() "my" files...

..oO(Joel Fireman)

>On a Linux server, a web page lets users enter items to an order
>sheet. When they finish, (besides the mysql db updates) the order data
>is emailed to the user as confirmation, a copy is emailed to the
>fulfillment people, and two files are written for pickup by a third
>party, in the third party's directory.
>
>Because the files are owned by apache, the third party cannot delete
>them, even when they are chmod'ed to 777. I tried to chown() the files
>to the third party's user, but no go.

The third party also needs write access to the directory where the files
are stored.

Micha

Re: Can"t chown() "my" files...

On Tue, 04 Dec 2007 23:22:24 +0100, Michael Fesser
wrote:

>.oO(Joel Fireman)
>
>>On a Linux server, a web page lets users enter items to an order
>>sheet. When they finish, (besides the mysql db updates) the order data
>>is emailed to the user as confirmation, a copy is emailed to the
>>fulfillment people, and two files are written for pickup by a third
>>party, in the third party's directory.
>>
>>Because the files are owned by apache, the third party cannot delete
>>them, even when they are chmod'ed to 777. I tried to chown() the files
>>to the third party's user, but no go.
>
>The third party also needs write access to the directory where the files
>are stored.
>
>Micha

Shazam!! Somewhere in the midst of flailing on this I had root owning
the 3rd party's dir... hmmmpff...

Well, at least he can delete the files after he reads them, now... and
that's all we really care about in this case.

But, if apache owns the file, how come he can't chown() it?

Re: Can"t chown() "my" files...

Joel Fireman wrote:
> On a Linux server, a web page lets users enter items to an order
> sheet. When they finish, (besides the mysql db updates) the order data
> is emailed to the user as confirmation, a copy is emailed to the
> fulfillment people, and two files are written for pickup by a third
> party, in the third party's directory.
>
> Because the files are owned by apache, the third party cannot delete
> them, even when they are chmod'ed to 777. I tried to chown() the files
> to the third party's user, but no go.
>
That is correct behavior - only root or the owner can change file
ownerships IIRC.


And it looks like changing owners doesn't entirely work when when its
your file you are giving away..ho hum.. I remember this from somewhere..

I'll try and find out the answer..got me irritated.

Ah. You cant delete files if you don't have write access to the
*directory* the file is in..?

You need to add your user to the group the directory belongs to and set
775 permissions on the DIRECTORY as well, I think.

Re: Can"t chown() "my" files...

Joel Fireman wrote:
> On Tue, 04 Dec 2007 23:22:24 +0100, Michael Fesser
> wrote:
>
>> .oO(Joel Fireman)
>>
>>> On a Linux server, a web page lets users enter items to an order
>>> sheet. When they finish, (besides the mysql db updates) the order data
>>> is emailed to the user as confirmation, a copy is emailed to the
>>> fulfillment people, and two files are written for pickup by a third
>>> party, in the third party's directory.
>>>
>>> Because the files are owned by apache, the third party cannot delete
>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>> to the third party's user, but no go.
>> The third party also needs write access to the directory where the files
>> are stored.
>>
>> Micha
>
> Shazam!! Somewhere in the midst of flailing on this I had root owning
> the 3rd party's dir... hmmmpff...
>
> Well, at least he can delete the files after he reads them, now... and
> that's all we really care about in this case.
>
> But, if apache owns the file, how come he can't chown() it?
>
apache can chown it.

Re: Can"t chown() "my" files...

Joel Fireman wrote:
> On Tue, 04 Dec 2007 23:22:24 +0100, Michael Fesser
> wrote:
>
>> .oO(Joel Fireman)
>>
>>> On a Linux server, a web page lets users enter items to an order
>>> sheet. When they finish, (besides the mysql db updates) the order data
>>> is emailed to the user as confirmation, a copy is emailed to the
>>> fulfillment people, and two files are written for pickup by a third
>>> party, in the third party's directory.
>>>
>>> Because the files are owned by apache, the third party cannot delete
>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>> to the third party's user, but no go.
>> The third party also needs write access to the directory where the files
>> are stored.
>>
>> Micha
>
> Shazam!! Somewhere in the midst of flailing on this I had root owning
> the 3rd party's dir... hmmmpff...
>
> Well, at least he can delete the files after he reads them, now... and
> that's all we really care about in this case.
>
> But, if apache owns the file, how come he can't chown() it?
>
>

If your system is set up properly, inly the owner or root can chown() a
file.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Can"t chown() "my" files...

On Tue, 04 Dec 2007 23:47:52 +0000, The Natural Philosopher
wrote:

>Joel Fireman wrote:
>> On Tue, 04 Dec 2007 23:22:24 +0100, Michael Fesser
>> wrote:
>>
>>> .oO(Joel Fireman)
>>>
>>>> On a Linux server, a web page lets users enter items to an order
>>>> sheet. When they finish, (besides the mysql db updates) the order data
>>>> is emailed to the user as confirmation, a copy is emailed to the
>>>> fulfillment people, and two files are written for pickup by a third
>>>> party, in the third party's directory.
>>>>
>>>> Because the files are owned by apache, the third party cannot delete
>>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>>> to the third party's user, but no go.
>>> The third party also needs write access to the directory where the files
>>> are stored.
>>>
>>> Micha
>>
>> Shazam!! Somewhere in the midst of flailing on this I had root owning
>> the 3rd party's dir... hmmmpff...
>>
>> Well, at least he can delete the files after he reads them, now... and
>> that's all we really care about in this case.
>>
>> But, if apache owns the file, how come he can't chown() it?
>>
>apache can chown it.

Not so far... here's the code:

//...
// 1. the csv for importing into the Office db
$filename = $writeorderfile.$mcnum.'.csv';
if (!$handle = fopen($filename, 'w')) {
echo "Cannot open file ($filename)";
exit;
}
if (fwrite($handle, $outcsv) === FALSE) {
echo "Cannot write CSV data to file ($filename)";
exit;
}
fclose($handle);
if (chown($filename,"orders")) {
echo "chowned() $filename";
}
else
{
echo "Couldn't chown $filename\n\n";
}

if ( chmod($filename,octdec("777"))) {
echo "chmodded() $filename";
}
else
{
echo "Couldn't chmod $filename\n\n";
}

The chmod works, the chown doesn't.

Re: Can"t chown() "my" files...

On Tue, 04 Dec 2007 21:05:25 -0500, Jerry Stuckle
wrote:

>Joel Fireman wrote:
>> On Tue, 04 Dec 2007 23:22:24 +0100, Michael Fesser
>> wrote:
>>
>>> .oO(Joel Fireman)
>>>
>>>> On a Linux server, a web page lets users enter items to an order
>>>> sheet. When they finish, (besides the mysql db updates) the order data
>>>> is emailed to the user as confirmation, a copy is emailed to the
>>>> fulfillment people, and two files are written for pickup by a third
>>>> party, in the third party's directory.
>>>>
>>>> Because the files are owned by apache, the third party cannot delete
>>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>>> to the third party's user, but no go.
>>> The third party also needs write access to the directory where the files
>>> are stored.
>>>
>>> Micha
>>
>> Shazam!! Somewhere in the midst of flailing on this I had root owning
>> the 3rd party's dir... hmmmpff...
>>
>> Well, at least he can delete the files after he reads them, now... and
>> that's all we really care about in this case.
>>
>> But, if apache owns the file, how come he can't chown() it?
>>
>>
>
>If your system is set up properly, inly the owner or root can chown() a
>file.

And?

Re: Can"t chown() "my" files...

On Tue, 04 Dec 2007 23:47:11 +0000, The Natural Philosopher
wrote:

>Joel Fireman wrote:
>> On a Linux server, a web page lets users enter items to an order
>> sheet. When they finish, (besides the mysql db updates) the order data
>> is emailed to the user as confirmation, a copy is emailed to the
>> fulfillment people, and two files are written for pickup by a third
>> party, in the third party's directory.
>>
>> Because the files are owned by apache, the third party cannot delete
>> them, even when they are chmod'ed to 777. I tried to chown() the files
>> to the third party's user, but no go.
>>
>That is correct behavior - only root or the owner can change file
>ownerships IIRC.
>
He (apache) IS the owner... dat's de point...

>
>And it looks like changing owners doesn't entirely work when when its
>your file you are giving away..ho hum.. I remember this from somewhere..
>
>I'll try and find out the answer..got me irritated.
>
>Ah. You cant delete files if you don't have write access to the
>*directory* the file is in..?

As mentioned elsewhere, yep, the third party ("orders") had had his
directory ownership changed to root... somewhere along the line... and
changing it back to orders now does allow him to delete files after
downloading them. An' dat's good.

>You need to add your user to the group the directory belongs to and set
>775 permissions on the DIRECTORY as well, I think.

Setting it to 777 didn't work, so I'm pretty sure 775 won't - nudge,
nudge... wink, wink... know what I mean?

At this stage, it's mainly for future reference: the functionality is
there, i.e., the order files are written to a directory owned by
"orders" and he can ftp 'em down and delete 'em.

.... but I'd still like to figger out why apache can CREATE a file, can
CHMOD the file, but he can't CHOWN the file and give it to the user
who actually owns the directory... grrrrr...

Re: Can"t chown() "my" files...

Joel Fireman wrote:
> On Tue, 04 Dec 2007 23:47:11 +0000, The Natural Philosopher
> wrote:
>
>>Joel Fireman wrote:
>>> On a Linux server, a web page lets users enter items to an order
>>> sheet. When they finish, (besides the mysql db updates) the order data
>>> is emailed to the user as confirmation, a copy is emailed to the
>>> fulfillment people, and two files are written for pickup by a third
>>> party, in the third party's directory.
>>>
>>> Because the files are owned by apache, the third party cannot delete
>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>> to the third party's user, but no go.
>>>
>>That is correct behavior - only root or the owner can change file
>>ownerships IIRC.
>>
> He (apache) IS the owner... dat's de point...
>
>>
>>And it looks like changing owners doesn't entirely work when when its
>>your file you are giving away..ho hum.. I remember this from somewhere..
>>
>>I'll try and find out the answer..got me irritated.
>>
>>Ah. You cant delete files if you don't have write access to the
>>*directory* the file is in..?
>
> As mentioned elsewhere, yep, the third party ("orders") had had his
> directory ownership changed to root... somewhere along the line... and
> changing it back to orders now does allow him to delete files after
> downloading them. An' dat's good.
>
>>You need to add your user to the group the directory belongs to and set
>>775 permissions on the DIRECTORY as well, I think.
>
> Setting it to 777 didn't work, so I'm pretty sure 775 won't - nudge,
> nudge... wink, wink... know what I mean?
>
> At this stage, it's mainly for future reference: the functionality is
> there, i.e., the order files are written to a directory owned by
> "orders" and he can ftp 'em down and delete 'em.
>
> ... but I'd still like to figger out why apache can CREATE a file, can
> CHMOD the file, but he can't CHOWN the file and give it to the user
> who actually owns the directory... grrrrr...
>
The linux man page of the chown system call states:
"Only a privileged process (Linux: one with the CAP_CHOWN capability)
may change the owner of a file. The owner of a file may change the
group of the file to any group of which that owner is a member."

So, no luck giving away the file.

Marc

Re: Can"t chown() "my" files...

Jerry Stuckle wrote:

> If your system is set up properly, inly the owner or root can chown() a
> file.

Actually, unless you've set your system up unusually, only root can.

Technically, the owner of the file *can* chown it, but they can't assign
ownership to any other user -- they can only chown it to themself, which
is rather pointless.

In short, unless you're root, you can't use chown to assign ownership to
someone else.

This is for very valid security reasons. You could, for instance, write
and compile a C program which did the equivalent of "rm -fr /", give it
permissions 4755 (executable and readable, with setuid bit), chown it to
root and then run it, wiping out the entire system.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 10 days, 18:14.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

Re: Can"t chown() "my" files...

Joel Fireman wrote:
> On Tue, 04 Dec 2007 23:47:11 +0000, The Natural Philosopher
> wrote:
>
>> Joel Fireman wrote:
>>> On a Linux server, a web page lets users enter items to an order
>>> sheet. When they finish, (besides the mysql db updates) the order data
>>> is emailed to the user as confirmation, a copy is emailed to the
>>> fulfillment people, and two files are written for pickup by a third
>>> party, in the third party's directory.
>>>
>>> Because the files are owned by apache, the third party cannot delete
>>> them, even when they are chmod'ed to 777. I tried to chown() the files
>>> to the third party's user, but no go.
>>>
>> That is correct behavior - only root or the owner can change file
>> ownerships IIRC.
>>
> He (apache) IS the owner... dat's de point...
>
>> And it looks like changing owners doesn't entirely work when when its
>> your file you are giving away..ho hum.. I remember this from somewhere..
>>
>> I'll try and find out the answer..got me irritated.
>>
>> Ah. You cant delete files if you don't have write access to the
>> *directory* the file is in..?
>
> As mentioned elsewhere, yep, the third party ("orders") had had his
> directory ownership changed to root... somewhere along the line... and
> changing it back to orders now does allow him to delete files after
> downloading them. An' dat's good.
>
>> You need to add your user to the group the directory belongs to and set
>> 775 permissions on the DIRECTORY as well, I think.
>
> Setting it to 777 didn't work, so I'm pretty sure 775 won't - nudge,
> nudge... wink, wink... know what I mean?
>
> At this stage, it's mainly for future reference: the functionality is
> there, i.e., the order files are written to a directory owned by
> "orders" and he can ftp 'em down and delete 'em.
>
> ... but I'd still like to figger out why apache can CREATE a file, can
> CHMOD the file, but he can't CHOWN the file and give it to the user
> who actually owns the directory... grrrrr...
>
>
Its just the way that Unix/Linux file perms work..

Re: Can"t chown() "my" files...

Toby A Inkster wrote:
> Jerry Stuckle wrote:
>
>> If your system is set up properly, inly the owner or root can chown() a
>> file.
>
> Actually, unless you've set your system up unusually, only root can.

I tested this last night. I was easily able to change a file that I
owned to somebody else..

No non standard permssions required.

>
> Technically, the owner of the file *can* chown it, but they can't assign
> ownership to any other user -- they can only chown it to themself, which
> is rather pointless.
>
> In short, unless you're root, you can't use chown to assign ownership to
> someone else.
>
> This is for very valid security reasons. You could, for instance, write
> and compile a C program which did the equivalent of "rm -fr /", give it
> permissions 4755 (executable and readable, with setuid bit), chown it to
> root and then run it, wiping out the entire system.
>

Re: Can"t chown() "my" files...

Toby A Inkster wrote:
> Jerry Stuckle wrote:
>
>> If your system is set up properly, inly the owner or root can chown() a
>> file.
>
> Actually, unless you've set your system up unusually, only root can.
>
> Technically, the owner of the file *can* chown it, but they can't assign
> ownership to any other user -- they can only chown it to themself, which
> is rather pointless.
>
> In short, unless you're root, you can't use chown to assign ownership to
> someone else.
>
> This is for very valid security reasons. You could, for instance, write
> and compile a C program which did the equivalent of "rm -fr /", give it
> permissions 4755 (executable and readable, with setuid bit), chown it to
> root and then run it, wiping out the entire system.
>

Nope, I can do it just find on my system. But your idea of rm -fr won't
work - the script will execute under the user's permissions. You would
have to change the su bit on the shell's executable - and only root can
do that.

Even chown'ing it to root will not make any difference as far as the
script goes. Ownership of the script does not affect permissions of the
user running the script.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Can"t chown() "my" files...

Jerry Stuckle wrote:
> Toby A Inkster wrote:
>> Jerry Stuckle wrote:
>>
>>> If your system is set up properly, inly the owner or root can chown() a
>>> file.
>>
>> Actually, unless you've set your system up unusually, only root can.
>>
>> Technically, the owner of the file *can* chown it, but they can't
>> assign ownership to any other user -- they can only chown it to
>> themself, which is rather pointless.
>>
>> In short, unless you're root, you can't use chown to assign ownership
>> to someone else.
>> This is for very valid security reasons. You could, for instance,
>> write and compile a C program which did the equivalent of "rm -fr /",
>> give it permissions 4755 (executable and readable, with setuid bit),
>> chown it to root and then run it, wiping out the entire system.
>>
>
> Nope, I can do it just find on my system. But your idea of rm -fr won't
> work - the script will execute under the user's permissions. You would
> have to change the su bit on the shell's executable - and only root can
> do that.
>
> Even chown'ing it to root will not make any difference as far as the
> script goes. Ownership of the script does not affect permissions of the
> user running the script.
>
unless it has su rights assigned to it.

Re: Can"t chown() "my" files...

The Natural Philosopher wrote:

> I tested this last night. I was easily able to change a file that I
> owned to somebody else.
>
> No non standard permssions required.

[tai@ophelia (pts/1) ~]$ cd /tmp/
[tai@ophelia (pts/1) /tmp]$ ls -ld .
drwxrwxrwt 38 root root 77824 2007-12-05 12:06 .
[tai@ophelia (pts/1) /tmp]$ touch chown-test
[tai@ophelia (pts/1) /tmp]$ ls -l chown-test
-rw-r--r-- 1 tai users 0 2007-12-05 12:11 chown-test
[tai@ophelia (pts/1) /tmp]$ chown root chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tai@ophelia (pts/1) /tmp]$ chown sk chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tai@ophelia (pts/1) /tmp]$ chown apache chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tai@ophelia (pts/1) /tmp]$ chown nobody chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tai@ophelia (pts/1) /tmp]$ ls -l chown-test
-rw-r--r-- 1 tai users 0 2007-12-05 12:11 chown-test
[tai@ophelia (pts/1) /tmp]$ uname -a
Linux ophelia.g5n.co.uk 2.6.17.14-mm-desktop-9mdvsmp #1 SMP PREEMPT Sat
Aug 11 13:17:52 EDT 2007 i686 Pentium III (Coppermine) GNU/Linux

regan:~ tai$ cd /tmp/
regan:/tmp tai$ ls -ld .
drwxrwxrwt 13 root wheel 442 Dec 5 12:14 .
regan:/tmp tai$ touch chown-test
regan:/tmp tai$ ls -l chown-test
-rw-r--r-- 1 tai wheel 0 Dec 5 12:14 chown-test
regan:/tmp tai$ chown root chown-test
chown: chown-test: Operation not permitted
regan:/tmp tai$ chown www chown-test
chown: chown-test: Operation not permitted
regan:/tmp tai$ ls -l chown-test
-rw-r--r-- 1 tai wheel 0 Dec 5 12:14 chown-test
regan:/tmp tai$ uname -a
Darwin regan.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

[tobyink@pr-shellA ~]$ cd /tmp
[tobyink@pr-shellA /tmp]$ ls -ld .
drwxrwxrwt 99 root root 12288 Dec 5 03:32 .
[tobyink@pr-shellA /tmp]$ touch chown-test
[tobyink@pr-shellA /tmp]$ ls -l chown-test
-rw-r--r-- 1 tobyink users 0 Dec 5 04:24 chown-test
[tobyink@pr-shellA /tmp]$ chown root chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tobyink@pr-shellA /tmp]$ chown apache chown-test
chown: changing ownership of `chown-test': Operation not permitted
[tobyink@pr-shellA /tmp]$ ls -l chown-test
-rw-r--r-- 1 tobyink users 0 Dec 5 04:24 chown-test
[tobyink@pr-shellA /tmp]$ uname -a
Linux pr-shellA.sourceforge.net 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27
10:11:19 EST 2007 i686 athlon i386 GNU/Linux


--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 10 days, 19:10.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

Re: Can"t chown() "my" files...

Joel Fireman wrote:

> On a Linux server, a web page lets users enter items to an order
> sheet. When they finish, (besides the mysql db updates) the order data
> is emailed to the user as confirmation, a copy is emailed to the
> fulfillment people, and two files are written for pickup by a third
> party, in the third party's directory.
>
> Because the files are owned by apache, the third party cannot delete
> them, even when they are chmod'ed to 777. I tried to chown() the files
> to the third party's user, but no go.

Check the manual page (http://no2.php.net/chown), you might know why:

> Only the superuser may change the owner of a file.

Namely, the user named "root".

--
Kim André Akerø
- kimandre@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)

Re: Can"t chown() "my" files...

The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> Toby A Inkster wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> If your system is set up properly, inly the owner or root can chown() a
>>>> file.
>>>
>>> Actually, unless you've set your system up unusually, only root can.
>>>
>>> Technically, the owner of the file *can* chown it, but they can't
>>> assign ownership to any other user -- they can only chown it to
>>> themself, which is rather pointless.
>>>
>>> In short, unless you're root, you can't use chown to assign ownership
>>> to someone else.
>>> This is for very valid security reasons. You could, for instance,
>>> write and compile a C program which did the equivalent of "rm -fr /",
>>> give it permissions 4755 (executable and readable, with setuid bit),
>>> chown it to root and then run it, wiping out the entire system.
>>>
>>
>> Nope, I can do it just find on my system. But your idea of rm -fr
>> won't work - the script will execute under the user's permissions.
>> You would have to change the su bit on the shell's executable - and
>> only root can do that.
>>
>> Even chown'ing it to root will not make any difference as far as the
>> script goes. Ownership of the script does not affect permissions of
>> the user running the script.
>>
> unless it has su rights assigned to it.
>

You can't assign su rights to a script. Actually, you can, but it won't
do any good. The script is not the executable. The shell driver
program is.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================