Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Suppose user "qqq" have file /home/qqq/bigfile.dat and want to pass it to user "aaa" without help of root (it need to be owned by "aaa"). What should users "qqq" and "aaa" do?

Naive way:

  1. uid=qqq$ mv bigfile.dat /home/aaa/
  2. uid=aaa$ chown aaa /home/aaa/bigfile.dat # Operation not permitted

Of course it can be done by using ACLs (uid=qqq$ setfacl u:aaa:rw- /home/aaa/bigfile.dat) or by making temporary copy (uid=aaa$ mv bigfile.dat bigfile.dat_ && cat bigfile.dat_ > bigfile.dat && rm bigfile.dat_), but both ways seem to have disadvantages.

Both users agree (can issue some command) to "pass" the file. It should be quick, preserving inode and other attributes etc.

How to do it cleanly?

share|improve this question
    
You seem to know how to give aaa full access to the file (regular permissions for group and others work for that too). What is it you must do that requires setting the file owner that you can't do now? –  Roger Pate Sep 6 '10 at 15:44
    
Actually it is needed because of no good answers for superuser.com/questions/152963/slave-user-accounts-in-gnu-linux –  Vi. Sep 6 '10 at 19:00
add comment

5 Answers

up vote 1 down vote accepted

Old unix systems allowed any user to chown their own files to any target. Most no longer do, because this created some security problems:

  • If there are disk usage quotas in place, user A could store files on user B's expense by putting them in a private directory. User B would never know except by comparing their visible disk usage with their quotas, and would have no way to find the quota thief.

  • Some privileged programs (set[ug]id executables or daemons) assume that if a file is owned by a user, that user has approved the content. If user A could chown a file to user B, A could trick the privileged program into accepting any data. (This is an insecure design anyway, because even if A has actually written the file, A might not have approved it for this particular purpose; but such programs do exist, and forbidding chowns does reduce the risks.)

  • A chown by a non-root user cannot be undone. Mind, it's a risk you might live with (and in fact there are other things that you can do on a unix filesystem that can only be undone if some other user cooperates).

As far as I know, it is impossible to change the ownership of a file on most modern unix systems without root's cooperation. Root could perform the chown or give A or B the permission to do it via sudo, but that requires more targeted root intervention than is usually desirable.

If ACLs are enabled, as you've noticed, that gives most of the practical effects of chowning.

If the workflow really requires A to be the owner at some point and B to be the owner at some other point, there are other options you could explore.

  • B might use fakeroot to run a program and make it believe it is running as root, which allows a simulated chown that exists only in fakeroot's memory (fakeroot sh -c 'chown B file; su B -c program').

  • You could play tricks with FUSE. For example bindfs lets you create a view of a directory tree where files have a different owner (mkdir view_for_B; bindfs -u B actual_directory view_for_B).

share|improve this answer
    
Of course I expect both users to show their agreement for such change. –  Vi. Sep 6 '10 at 18:47
add comment

Can you move the file to some shared space that both users have write access to (or does that sort of thing not exist on Linux?), and then have the owner chmod it to the receiver?

My mindset is rooted in Mac OS X, so that may or may not work for you.

share|improve this answer
    
That does exist on Linux, but you can't chown as a regular user. –  Roger Pate Sep 6 '10 at 15:41
add comment

It depends on what you mean by "without help from root". If you can get root to add aaa and qqq to some new group (any name will do) and make sure the file has at least r-- perms for the new group... (it can retain rwx for user aaa - so you get => aaa:newgroup rw-r----- ) then without FURTHER help from root aaa can modify and qqq can read the same file.

If you want to do it "against the wishes of root" then I'd consider it a bug if you found any way that works. Lots of thought went into preventing this because it's a security problem if aaa can put a trojan into a directory that qqq has access to and might "accidently" then run.

share|improve this answer
    
You probably haven't understood the question. Users are already in some same group (otherwise mv bigfile.dat /home/aaa/ will fail or require over-accessible permissions for /home/aaa). The question is about changing file's metadata. –  Vi. Sep 7 '10 at 23:58
add comment

Ok, it's really cheeky but you could do:

aaa$ nc -l -p 12000 > bigfile.dat
qqq$ nc 127.0.0.1 12000 < bigfile.dat

Or

aaa$ mkfifo /tmp/gimme
aaa$ chmod a+w /tmp/gimme
aaa$ cat /tmp/gimme > bigfile.dat
qqq$ cat bigfile.dat > /tmp/gimme

If you want to do it without needing enough space for 2 copies of bigfile.dat, you could use split and write a loop to send 1 chuck at a time and then rm it straight away.

The main issue is of course that someone else could do a nc or an echo and corrupt your file.

share|improve this answer
    
The question is "without creating any copies of it". –  Roger Pate Oct 12 '10 at 14:08
    
Think of it as moving the file one chunk at a time. At no point would two copies of the file exist so I reckon it's close enough. –  Henry Slater Oct 12 '10 at 16:45
    
I don't want methods which introduce too much overhead compared to root-assisted case. –  Vi. Oct 13 '10 at 13:02
    
Define overhead. I suspect the minimum to do it in any kind of secure manner is going to be one command for each user. –  Henry Slater Oct 13 '10 at 21:13
    
how about a whole load of directories and a cron job that moves the files about? –  Henry Slater Oct 13 '10 at 21:19
add comment

One way to do this would be to create a ssh-key which allows user qqq to connect as aaa. As qqq do

ssh-keygen -t rsa

and decide if you want to go for passwordless key or not.

Then add the newly created key to aaa by running this as qqq:

ssh-copy-id -i ~/.ssh/id_rsa.pub aaa@localhost

After that you could move files around like this:

scp bigfile.dat aaa@localhost:

(or with your favourite sftp client)

That way sshd would take care of changing the ownership.

Using scp/sftp for local transfer might sound strange, but at least that works! :)

share|improve this answer
    
1. It is not network case. 2. I do not want a copy of the file to be created. Suppose file is 4 GB and the entire storage is 5 GB. –  Vi. Sep 6 '10 at 9:47
1  
3. I do not want to give user "qqq" the access to "aaa". –  Vi. Sep 6 '10 at 9:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.