Sticky bit enabled on a file with no permissions
 

Hello everyone,

I'm exploring Linux permissions, and I have a question.
Does the user 'bob' have the ability to delete 'file.txt'?
The permissions for this file are as follows:

--------T 1 bob bob 0 Nov 05 23:01 file.txt.

The presence of the capital letter 'T' at the end indicates that the sticky bit is set on the directory containing 'file.txt,' while all other permissions are absent. The user "bob" appears to be the owner of the file, does the presence of the sticky bit enable him to delete it?

Thanks in advance!

Welcome to LQ.

No. The sticky bit doesn't mean that.

Right now the permissions need to be modified to be able to delete the file.

Perhaps you should try experiments with junk files to learn better.

Thank you for your answer.

Understood. So I still need to grant write permission to the user 'bob' for that file in order for him to be able to delete it?

 

Deleting a file checks the permission on the directory, not on the file.

(There was a thread or two on the subject a few months back, but I did a few searches and couldn't find them.)

Really?? I believe you are thinking about directory permissions, not file permissions.

The rm command will ask for confirmation before removing a write-protected file, but will happily do so if you respond "y". It will remove the file without confirmation if you use the "-f" option. Many (most?) GUI file managers will happily trash or delete such a file without confirmation, at least in my experience.

Ability to delete a file requires write permission for the directory, not for the file itself. The sticky bit on a directory means that you cannot delete a file there unless you own either that file or the directory itself (or are "root", of course).

Sorry, my mistake, the others have it correctly.

More typically for me the files and directories I have, do not have unusual permissions. The occasions where I run into something blocking a deletion, it's typically because the file is in use. Like for me I never kill my editor but after completing a merge, I may remove the directory copy of the git workspace to create a fresh clone. An open file in my editor stops that, temporarily.

If this is just learning, all fine, but in my opinion you normally (as a user) would not have permissions like that. I can't recall any situation where I wanted or needed the sticky bit, nor had zero permissions for a file.

Seems like a homework assignment..

The answer to the posted questions would be "there's no way to tell from the information provided", which is not what you'd normally expect of the answer to a homework question, at least not at this level. It could be homework, but IMO there's enough wiggle room here to let it slide.

Permissions in UNIX are a little unintuitive. That directory permissions control creation/deletion, and that the last 3 bits being 'others' rather than 'everyone', and that both user and group permissions bits can be both permissive and restrictive takes a while to get your head around. And all that's before you get into ACLs! ;)

Why not create yourself a directory and play with the permissions? It's the best way to investigate this stuff.

In Unix the file permission controls how you can access its data (contents).
A deletion of a file is initiated by unlinking its data from the directory: you must have write permission on the directory. Then the kernel deletes the file's data (list of data blocks), unless a process still accesses it or it's linked to yet another directory. If there is no access and the link count is 0 then the kernel deletes the data (frees the data blocks.)

The t-bit ("sticky bit") on a file has no real meaning,
Some old Unixes took it as a hint to cache it longer in RAM; some other Unixes took it as a hint to not fragment it.