Find files in not readable directory LINUX - linux

How to find all files in non readable directory
For example directory /home is locked perm 40700
But I can read all files in this directory like
/home/index.php and etc
How to list all files in this directory?
I tryed ls and find function do not want to find thoose files

The r permission of folders determines whether you can list the contents. If a folder has x but not r, then you can access files as long as you know their names.
An example for this is to allow users to publish HTML documents in their home folders. For this, set the permissions for /home/user to rwx-----x and /home/user/public_html to rwx---r-x
That way, the HTML server can access the folder (it can walk though your home folder) but it can't see any files outside of the public_html folder.

Related

Can't get into a directory

for file in os.listdir(r'C:\Users\user\Downloads\plant_tomato_leaf_dataset\plantvillage'):
for cl in os.listdir(r'C:\Users\user\Downloads\plant_tomato_leaf_dataset\plantvillage\\'+file):
print(file)
print(cl)
print('******************')
I have a folder "plantvillage". Inside that folder I have 10 folder. I have to access all the sub-folders and perform operations on those sub-folder-items. But this code is showing only items of the first folder
You might be interested in os.walk instead of os.listdir. listdir is not recursive.
An example would be:
for root, dirs, files in os.walk(r'C:\Users\user\Downloads\plant_tomato_leaf_dataset\plantvillage'):
for file in files:
print(os.path.join(root,file))
this will run the inner loop as many times as there are directories, and will also check to make sure that each file is actually a file. If you want to look at the directories themselves for some reason (ignoring files), you can do that like so:
for root, dirs, files in os.walk(r'C:\Users\user\Downloads\plant_tomato_leaf_dataset\plantvillage'):
for directory in dirs:
print(os.path.join(root,directory))
but don't try to mix and match. Getting the current directory is easy when iterating files. It's just root.

Not symlinking one or two files inside symlinked directory

Is there a way not to symlink one or two files within a symlinked directory in CentOS?
I've got the entire directory symlinked but there are two css files that I would like to use the current copy for the website
In short: no.
Another way to do this would be to symlink all the files in that directory, except those you want local copy of.
Still another way to go might be using unionfs or aufs to union-mount the original directory and a directory containing the files you need local, with the directory containing local files being "on top".
Say, your original directory is orig, the directory with files that should be local is local, the union directory is union, and you want files from both directories to be writable. Then you can union-mount them like this:
unionfs-fuse local=RW:orig=RW union
And unmount like this:
fusermount -u union
See unionfs manpage (unionfs-fuse(8) at least on Debian) for details.

Create a user level 777 directory inside root directory /

I need to put the Dropbox folder inside the root path, this way:
cd /Dropbox
I can't create first a normal folder because Dropbox automatically creates a Dropbox folder nested in it...
so it would result in this (like It does now)
cd /folder/Dropbox
What would be the problem if I give a "sudo chmod +w /"?
So I could initialize Dropbox inside the root path?
No problem if other files would be written in the / since there are no important files loaded in there, and anyway users wouldn't be allowed to write in the subfolder like /etc. Is that right?

Wget - output directory prefix

Currently I try to use:
"wget --user=xxx --password=xxx -r ftp://www.domain.com/htdocs/"
But this saves output files to current directory in this fashion:
curdir/www.domain.com/htdocs/*
I need it to be:
curdir/*
Is there a way to do this, I only see a way to use output prefix, but i think this will just allow me to define directory outside current dir?
You can combine --no-directories if you want all your files inside one directory or --no-host-directories to have subdirectories but no subdirectories per host with your --directory-prefix option.
2.6 Directory Options
‘-nd’
‘--no-directories’
Do not create a hierarchy of directories when retrieving recursively. With this option turned on, all files will get saved to the current directory, without clobbering (if a name shows up more than once, the filenames will get extensions ‘.n’).
‘-nH’
‘--no-host-directories’
Disable generation of host-prefixed directories. By default, invoking Wget with ‘-r http://fly.srk.fer.hr/’ will create a structure of directories beginning with fly.srk.fer.hr/. This option disables such behavior.
‘-P prefix’
‘--directory-prefix=prefix’
Set directory prefix to prefix. The directory prefix is the directory where all other files and subdirectories will be saved to, i.e. the top of the retrieval tree. The default is ‘.’ (the current directory).
(From the wget manual.)

Linux folder permissions

At my office, we have a network directory structure like this:
/jobs/2004/3999-job_name/...
/jobs/2004/4000-job_name/...
The issue is that employees rename the "4000-job_name" folders (which in turn breaks other things that rely on the name being consistent with a database).
How can I stop users from renaming the parent folder while still allowing them full control of that folder's contents?
Please keep in mind that this is a Samba share that Windows users will be accessing.
I think you want to do this:
chmod a=rx /jobs #chdir and lsdir allowed, modifying not
chmod a=rwx /jobs/* #allow everything to everyone in the subdirectories
Since the directories /jobs/* are in fact files in /jobs their names cannot be changed without the write permission for /jobs. In the subdirectories of /jobs/ everyone is allowed to do anything with the commands above.
Also, be sure to set the permissions of new directories to rwx as you add them.
(edit by Bill K to fix the examples--the solution was correct but he misread the question due to the strange coloring SO added)
The question has already been answered, so I'm just gonna make a brief remark: in your question, you use the terms "folder" and "directory" interchangeably. Those two are very different, and in my experience 99% of all problems with Unix permissions have to do with confusing the two. Remember: Unix has directories, not folders.
EDIT: a folder is two pieces of cardboard glued together, that contain files. So, a folder is a container, it actually physically contains the files it holds. So, obviously a file can only be in one container at a time. To rename a file, you not only need access to the folder, you also need access to the file. Same to delete a file.
A directory, OTOH, is itself a file. [This is, in fact, exactly how directories were implemented in older Unix filesystems: just regular files with a special flag, you could even open them up in an editor and change them.] It contains a list of mappings from name to location (think phone directory, or a large warehouse). [In Unix, these mappings are called links or hardlinks.] Since the directory only contains the names of the files, not the files themselves, the same file can be present in multiple directories under different names. To change the name of a file (or more precisely to change a name of a file, since it can have more than one), you only need write access to the directory, not the file. Same to delete a file. Well, actually, you can't delete a file, you can only delete an entry in the directory – there could still be other entries in other directories pointing to that file. [That's why the syscall/library function to delete a file is called unlink and not delete: because you just remove the link, not the file itself; the file gets automatically "garbage collected" if there are no more links pointing to it.]
That's why I believe the folder metaphor for Unix directories is wrong, and even dangerous. The number one security question on one of the Unix mailinglists I'm on, is "Why can A delete B's files, even though he doesn't have write access to them?" and the answer is, he only needs write access to the directory. So, because of the folder metaphor, people think that their files are safe, even if they are not. With the directory metaphor, it would be much easier to explain what's going on: if I want to delete you from my phonebook, I don't have to hunt you down and kill you, I just need a pencil!
If you make the parent directory--/jobs/2004/--non-writable for the users, they won't be able to rename that folder.
I did the following experiment on my own machine to illustrate the point:
ndogg#seriallain:/tmp$ sudo mkdir jobs
ndogg#seriallain:/tmp$ sudo mkdir jobs/2004
ndogg#seriallain:/tmp$ sudo mkdir jobs/2004/3999-job_name/
ndogg#seriallain:/tmp$ cd jobs/2004/
ndogg#seriallain:/tmp/jobs/2004$ sudo chown ndogg.ndogg 3999-job_name/
ndogg#seriallain:/tmp/jobs/2004$ ls -alh
total 12K
drwxr-xr-x 3 root root 4.0K 2009-03-13 18:23 .
drwxr-xr-x 3 root root 4.0K 2009-03-13 18:23 ..
drwxr-xr-x 2 ndogg ndogg 4.0K 2009-03-13 18:23 3999-job_name
ndogg#seriallain:/tmp/jobs/2004$ touch 3999-job_name/foo
ndogg#seriallain:/tmp/jobs/2004$ mv 3999-job_name/ blah
mv: cannot move `3999-job_name/' to `blah': Permission denied

Resources