Cannot chown as a user

[Michael Williams_6]

Right, I'm completely stuck here...

I've got several new Linux systems, and I'm unable to chown files as users, even if the user owns the file. We're running SLES8, fully patched. We're running a shoddy ksh compiled from source, with an in-built chown, but the problem also occurs with /bin/chown. It also happens with bash, so something is wrong somewhere.

We're using the reiserfs filesystem, and are in a NIS domain that is served by a SCO system.

Here's an indication of the problem, I'm trying to chown a file I own, in a directory I own to someone else:

michaelw@linpo: pwd
/tmp/miketest
michaelw@linpo: ls -l
total 0
-rw-rw-r-- 1 michaelw alch 0 2004-05-10 10:35 testfile
michaelw@linpo: ls -ld .
drwxrwxr-x 2 michaelw alch 72 2004-05-10 10:35 .
michaelw@linpo: /bin/chown webuser testfile
/bin/chown: changing ownership of `testfile': Operation not permitted
michaelw@linpo: mount
/dev/ida/c0d0p2 on / type reiserfs (rw)
michaelw@linpo: grep c0d0p2 /etc/fstab
/dev/ida/c0d0p2 / reiserfs defaults 1 1
michaelw@linpo: ls -l /bin/chown
-rwxr-xr-x 1 root root 20024 2002-10-16 14:01 /bin/chown
michaelw@linpo: lsattr testfile
--------------- testfile
michaelw@linpo: ypmatch michaelw passwd
michaelw:JCB19sWGJFrMw:456:100:Michael Williams:/homes/michaelw:/bin/ksh
michaelw@linpo: ypmatch webuser passwd
webuser:tpdPZ9BoF33U.:513:202:Web User Account:/homes/webuser:/bin/ksh

Anybody got any ideas? strace's are available, but mean bugger all to me!

Cheers for any help!

Mike

[Alexander Chuzhoy]

As far as I remember -root is the only one who can...

[Michael Williams_6]

I can't believe that, even on security grounds, I own the file!

If the file is owned by someone else, and I touch it, then I become the owner, so it must be possible!

[Alexander Chuzhoy]

anyway if you SUID the command:
chmod +s /bin/chown

then it works...

[Michael Williams_6]

Cheers, but no:

michaelw@linpo: ls -l /bin/chown
-rwxr-xr-x 1 root root 20024 2002-10-16 14:01 /bin/chown
michaelw@linpo: sudo chmod +s /bin/chown
Password:
michaelw@linpo: ls -l /bin/chown
-rwsr-sr-x 1 root root 20024 2002-10-16 14:01 /bin/chown
michaelw@linpo: chown webuser testfile
-ksh: chown: testfile: cannot change owner [Operation not permitted]

[Mark Grant]

If you have "capabilities" installed and set up then the entire security paradigm changes. Root does not necessarily have permissions to change a file and neither do you, even if you own it.

If you really have "capabilites" installed and you don't want it, you will need a kernel compile to get rid of it probably.

It's a big subject but you could start here.

http://www.linuxsecurity.com/feature_stories/kernel-24-security.html

[Michael Williams_6]

Mark,

I think you're on the right track here, we're running Kernel 2.4.19, which is the unpatched stock default that comes with SLES8, but the behaviour also occurs on patched kernels.

Having used Linux for a couple of months, this is all pretty new to me, doing google on Linux Capabilities pointed me to the /usr/include/linux/capability.h file which does contain this line:

#define CAP_CHOWN 0

It also mentions /proc/sys/kernel/cap-bound, but this is set to -257.

While this is all well and good it's not in english! Does this mean that CAP_CHOWN is in place, or does it mean it's not? If it is in place, how do I re-enable it?!

I don't appear to have lcap on the system, there's no man page and it's not in roots path...

[Michael Williams_6]

Ignore my last comment, further searching shows capabilities don't appear to be enabled:

linpo:/tmp/miketest # getcap testfile
Failed to get capabilities for file `testfile'
(Function not implemented)

[Mark Grant]

I think we are on dodgy ground here because as someone who worked on a C1/B2 secure unix for a year or so, I absolutley loath capabilities and have never set them up. However, my /proc/sys/kernel/cap-bound says the same as yours.

If you are using stock kernels then capabilities should not be in use. Can you confirm that if you create a file now, you can not change it's ownership or is it a file that already exists that you have this problem on?

[Michael Williams_6]

Hi Mark, this happens with both new and old files alike...

[Mark Grant]

Assuming it doesn't matter which directory this file is created in for a moment. I think it's time to look at NIS.

I don't think reiserfs is your problems here. I would make sure you don't have your user name in /etc/passwd and in the NIS maps, perhaps with different UID's

[Michael Williams_6]

Oooh you're good, I've just su'd to a local user and tried the whole thing again and it appears to work.

Is there some PAM modifications I need to make regarding NIS and chown or something?

Anyone know?!?

[Mark Grant]

I don't think PAM is your problem, especially if you can log in and everything. My guess is that your user in NIS has a different UID that the one in /etc/passwd.

Been a while since I "did" NIS but a believe "ypcat passwd | grep " should give you the user id that the NIS maps have and "grep /etc/passwd" should show you the name in /etc/passwd.

To be honest, you shouldn't have the user name in both so another solution may be to remove your user and see if you can still log in and everything starts working again. OF COURSE, remember that if you can't log in, you will need another account to get yourself working again.

[Olivier Drouin · Accepted solution]

If I remember correctly, the thinkind behind the "a normal user cant chown any file" is that it would allow a user to bypass the disk quotas...

[Yong_7]

Hi Guys,

I'm with Olivier.

Generally, we can't "chown" our own files to others except we are "root accounts" on any unix-like system.

this is system security sense that prevent things happening like people throw "snow ball" ( your files) to each other.

if your are planing file xfer within your group. group permission setting is your Friends. hence, you may let us know what function/capability you are looking for ( file sharing ? ). people here definitely have a lot hints for your reference.

Cheers !

YJ

[Alexander Chuzhoy]

Then Yong is probably with me also...

The only reason Michael could chown his file-is because he already ran the SUID command on /bin/chown.

[Michael Williams_6]

Hi guys thanks for your help! After enough digging I was able to confirm that chown is priviliged only for root for security reasons.

e.g. create yourself a set-uid script and chown it to root and you've got a problem on your hands!

We've done a work-around to our problem by using groups and the chgrp command to achieve what we need!