filesystems – Taking File Ownership When File and Directory Are Readable/Writable

chownfilesystemspermissions

I got some files in directory:

drwxrws-wt 2 me      mygroup  4,0K 10.1. 12:34 .
-rw-r----- 1 someone mygroup  10G  10.1. 11:22 someonesfile

me and someone are regular users without supplementary groups.

How to take ownership of that file using `me` account?

If me do:

$ chown me someonesfile
chown: doing bla bla bla: permission denied

However me can "change" ownership by replacing file with new one:

cp someonesfile myfile && mv -f myfile someonesfile`

So my main question is if there is any easier (cheaper) way to change file ownership in described environment without using root account or other privilege elevations. Basically I wanted to know if me can somehow take advantage of directory permissions to somehow reset ownership/permissions without making copy of whole file.

I've also noticed that editing file with vim and forcing overwrite with :w! will change owner of file, is that same as doing cp && mv? At least touch someonesfile will fail with permission denied.

Best Answer

Yes, vim will remove the original file and create a new one to put the new content in.

Your cp && mv -f is the way to go.

Note that when the t bit is set on the directory as it is in your case, it's not enough to have write permission to the directory you also need to be the owner of the file or the directory (as you are).

Related Solutions

Shell Command – How to Clone Ownership and Permissions from Another File

On GNU/Linux chown and chmod have a --reference option

chown --reference=otherfile thisfile
chmod --reference=otherfile thisfile

Linux – How fakeroot is not a security breach in Linux

So far, what I can gather is that fakeroot is used to give ownership to a file that needs to be root when it is unzip/tar'ed. My question, is why can't you just do that with chown?

Because you can’t just do that with chown, at least not as a non-root user. (And if you’re running as root, you don’t need fakeroot.) That’s the whole point of fakeroot: to allow programs which expect to be run as root to run as a normal user, while pretending that the root-requiring operations succeed.

This is used typically when building a package, so that the installation process of the package being installed can proceed without error (even if it runs chown root:root, or install -o root, etc.). fakeroot remembers the fake ownership which it pretended to give files, so subsequent operations looking at the ownership see this instead of the real one; this allows subsequent tar runs for example to store files as owned by root.

How does fakeroot stop unwanted privilege escalations on Linux? If fakeroot can trick tar into making a file that was owned by root, why not do something similar with SUID?

fakeroot doesn’t trick tar into doing anything, it preserves changes the build wants to make without letting those changes take effect on the system hosting the build. You don’t need fakeroot to produce a tarball containing a file owned by root and suid; if you have a binary evilbinary, running tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, as a regular user, will create a tarball containing evilbinary, owned by root, and suid. However, you won’t be able to extract that tarball and preserve those permissions unless you do so as root: there is no privilege escalation here. fakeroot is a privilege de-escalation tool: it allows you to run a build as a regular user, while preserving the effects the build would have had if it had been run as root, allowing those effects to be replayed later. Applying the effects “for real” always requires root privileges; fakeroot doesn’t provide any method of acquiring them.

To understand the use of fakeroot in more detail, consider that a typical distribution build involves the following operations (among many others):

install files, owned by root
...
archive those files, still owned by root, so that when they’re extracted, they’ll be owned by root

The first part obviously fails if you’re not root. However, when running under fakeroot, as a normal user, the process becomes

install files, owned by root — this fails, but fakeroot pretends it succeeds, and remembers the changed ownership
...
archive those files, still owned by root — when tar (or whatever archiver is being used) asks the system what the file ownership is, fakeroot changes the answer to match the ownership it recorded earlier

Thus you can run a package build without being root, while obtaining the same results you’d get if you were really running as root. Using fakeroot is safer: the system still can’t do anything your user can’t do, so a rogue installation process can’t damage your system (beyond touching your files).

In Debian, the build tools have been improved so as not to require this any more, and you can build packages without fakeroot. This is supported by dpkg directly with the Rules-Requires-Root directive (see rootless-builds.txt).

To understand the purpose of fakeroot, and the security aspects of running as root or not, it might help to consider the purpose of packaging. When you install a piece of software from source, for use system-wide, you proceed as follows:

build the software (which can be done without privileges)
install the software (which needs to be done as root, or at least as a user allowed to write to the appropriate system locations)

When you package a piece of software, you’re delaying the second part; but to do so successfully, you still need to “install” the software, into the package rather than onto the system. So when you package software, the process becomes:

build the software (with no special privileges)
pretend to install the software (again with no special privileges)
capture the software installation as a package (ditto)
make the package available (ditto)

Now a user completes the process by installing the package, which needs to be done as root (or again, a user with the appropriate privileges to write to the appropriate locations). This is where the delayed privileged process is realised, and is the only part of the process which needs special privileges.

fakeroot helps with steps 2 and 3 above by allowing us to run software installation processes, and capture their behaviour, without running as root.