Prev: Dealing with different number of fields in a file
Next: Linuxrc and nash
From: Jon LaBadie on 28 Apr 2010 16:27
Stachu 'Dozzie' K. wrote:
> On 2010-04-28, pk <pk(a)pk.invalid> wrote:
>> George wrote:
>>
>>> Dear All,
>>>
>>> I am trying to change the owner of a file on my Linux system and it is
>>> giving me an error message saying that I am not the owner. However,
>>>
>>> >whoami
>>> city
>>> > ls -l test.sh
>>> -rwxr-xr-- 1 city web 182 Apr 28 12:50 test.sh
>>> >chown web test.sh
>>> chown: test.sh: Not owner
>>>
>>> What could be wrong? I am running these commands not as a super-user,
>>> but as the owner of the file I should be able to change ownership -
>>> unless there is something that I am completely overlooking.
>> I think this is an historical matter; changing ownership of files to some
>> other user could be used maliciously to escape quotas and other tricks, so I
>> think you need to be either root or have a special Linux capability to do
>> what you're trying to do.
>
> Right. And add the following scenario that would be possible if you
> could change ownership without root privs:
> #v+
> mkdir blah
> chmod a+w blah
> cat /bin/sh > blah/rootshell
> chown root blah/rootshell
> chmod 4755 blah/rootshell
> blah/rootshell
> #v-
>

The final chmod would be forbidden because rootshell was "given away"
to root and now the ordinary user is no longer the owner.
From: pk on 28 Apr 2010 16:36
Jon LaBadie wrote:

>> Right. And add the following scenario that would be possible if you
>> could change ownership without root privs:
>> #v+
>> mkdir blah
>> chmod a+w blah
>> cat /bin/sh > blah/rootshell
>> chown root blah/rootshell
>> chmod 4755 blah/rootshell
>> blah/rootshell
>> #v-
>>
>
> The final chmod would be forbidden because rootshell was "given away"
> to root and now the ordinary user is no longer the owner.

I suppose one could chmod it first, and then chown...

From: Jon LaBadie on 28 Apr 2010 17:38
pk wrote:
> Jon LaBadie wrote:
>
>>> Right. And add the following scenario that would be possible if you
>>> could change ownership without root privs:
>>> #v+
>>> mkdir blah
>>> chmod a+w blah
>>> cat /bin/sh > blah/rootshell
>>> chown root blah/rootshell
>>> chmod 4755 blah/rootshell
>>> blah/rootshell
>>> #v-
>>>
>> The final chmod would be forbidden because rootshell was "given away"
>> to root and now the ordinary user is no longer the owner.
>
> I suppose one could chmod it first, and then chown...
>

No, chown specifically removes the setuid/setgid bits if the
user is not root. So the chown would clear them.
From: pk on 28 Apr 2010 17:47
Jon LaBadie wrote:

> pk wrote:
>> Jon LaBadie wrote:
>>
>>>> Right. And add the following scenario that would be possible if you
>>>> could change ownership without root privs:
>>>> #v+
>>>> mkdir blah
>>>> chmod a+w blah
>>>> cat /bin/sh > blah/rootshell
>>>> chown root blah/rootshell
>>>> chmod 4755 blah/rootshell
>>>> blah/rootshell
>>>> #v-
>>>>
>>> The final chmod would be forbidden because rootshell was "given away"
>>> to root and now the ordinary user is no longer the owner.
>>
>> I suppose one could chmod it first, and then chown...
>>
>
> No, chown specifically removes the setuid/setgid bits if the
> user is not root. So the chown would clear them.

Uhm, not necessarily, at least after a quick reading of the standard.

"If the specified file is a regular file, one or more of the S_IXUSR,
S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not
have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID
(S_ISGID) bits of the file mode shall be cleared upon successful return from
chown(). If the specified file is a regular file, one or more of the
S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process
has appropriate privileges, it is implementation-defined whether the set-
user-ID and set-group-ID bits are altered."

My understanding is that here we're in the "process has appropriate
privileges" case, as we are assuming that the owner can change ownership of
the file.

So it seems it's implementation defined (though I agree that probably most
if not all implementations clear the bits anyway).

I may be missing or misreading something though.
From: Ben Bacarisse on 28 Apr 2010 18:13
George <me(a)me.com> writes:

> Ben Bacarisse wrote:
>> George <me(a)me.com> writes:
>>
>>> I am trying to change the owner of a file on my Linux system and it is
>>> giving me an error message saying that I am not the owner. However,
>>>
>>>> whoami
>>> city
>>>> ls -l test.sh
>>> -rwxr-xr-- 1 city web 182 Apr 28 12:50 test.sh
>>>> chown web test.sh
>>> chown: test.sh: Not owner
>>>
>>> What could be wrong? I am running these commands not as a super-user,
>>> but as the owner of the file I should be able to change ownership -
>>> unless there is something that I am completely overlooking.
>>
>> The owner of a file can't change it's ownership, at least not in an
>> unrestricted way. You can change the group ownership to another group
>> to which you belong, but that's about it.
>>
> Is that not contradicted by the following excerpt from the man page of
> chown?
>
> The chown utility will set the user ID of the file named by
> each file to the user ID specified by owner, and, option-
> ally, will set the group ID to that specified by group.
>
> If chown is invoked by other than the super-user, the set-
> user-ID bit is cleared.
>
> Only the owner of a file (or the super-user) may change the
> owner of that file.

I can't see any contradiction. The last part raises some false hopes
but it falls short of saying that you can give away ownership.

BTW, how old is that man page? It seems to share no text at all with the
man page I have.

--
Ben.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Dealing with different number of fields in a file
Next: Linuxrc and nash