Hi guys,
I am using openSUSE 12.3 with xfce desktop and thunar file manager.Now I want to hide all directories under root directory.Actually I thought of removing the file manager but I need to view the pen drives in GUI mode.Is there a way to hide those files.
thanks in advance.
By “root directory”, do you mean the starting point of the directory tree, or the home directory of the root account (/root)? Access to the latter is restricted to root, and it shouldn’t be necessary to hide it.
Hiding everything under ‘/’ probably isn’t possible, and not practical, as users’ home directories are there. Maybe if you give some details on what your situation is, people will have other ideas to accomplish this.
Actually I mean the users should not be able to see the directories under root in GUI mode and in other words I need a KIOSK mode.
There’s a kiosktool for KDE. I’ve never used it, but it might worth a look.
Yeah thanks for the reply but we have some 100 systems with XFCE desktop environment and we are not allowed to change to KDE
On 2013-05-04 21:36, nishanth9042 wrote:
>
> Yeah thanks for the reply but we have some 100 systems with XFCE desktop
> environment and we are not allowed to change to KDE
Well, hiding directories not created by you is impossible, because in
Linux hiding means changing the name, and applications needing those
directories will not find them.
For example, this is a 12.3 default root directory listing:
eleanor3:~ # ls /
bin boot data dev etc home lib lib64 lost+found media mnt opt
proc root run sbin selinux srv sys tmp usr var
eleanor3:~ #
Of the above, the only one that can be hidden is “data”, because I
created it - and as it is a mount point, I have to edit fstab so that
mounts work.
If what you need is a kiosk, you will have to choose one that is
available, and use it. If it needs changing to KDE, so be it.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Three options:
One:
Subdirectories can he “hidden” by removing the read permission from the parent, thus if you did:
chmod o-r /
You would “hide” all contents of the root directory from all non-root users. However, users would still be able to navigate to subdirs if they knew the path, for example they could view /home/them, /var/lib/mysql, /etc … in thunar if typed in. Of course, you could apply the same to /etc/, /var/, etc. While this security through obscurity approach might work, its obviously limited. Further, removing read permission from / may likely cause unexpected consequences. While most services (mysql, apache, etc) would not be affected (as the dirs they access are owned by them or root) you will may encounter issues. You could test it out easily enough.
Hummm. . . I wonder if you used an ACL and prevented read access to / for all a group to which all users belonged?
setfacl -m g:users:x /
Seems to work pretty well, and is more granular. You could experiment with applying this where needed to limit access.
Two:
While nautilus will parse a .hidden file if present to mask directories, thunar will not do so without being patched. I appears someone has been done this road before and created a patch to do this, see:
And the patch at:
https://bugzilla.xfce.org/show_bug.cgi?id=3189
Three:
There was once a kernel patch called LIDS which prevented user space access to system directories, among other things. However, that project has been dormant for a while now. Perhaps you could find something similar.
On 2013-05-05 00:56, LewsTherinTelemon wrote:
> One:
> Subdirectories can he “hidden” by removing the read permission from the
> parent, thus if you did:
This breaks the system, as not all things run as root.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
I’m not sure if this would work. You would have to test it to see.
That should work, as long as thunar does not reset its sgid privilege.
I’d argue its not quite that clear cut that “this breaks the system as not all things run as root” - which of course I never said they did. A system service will a) run either as root, apache, mysqld, etc. b) will not require “other” read access referencing / (unless you can give an example where this is not true?) and d) any syscall to access or fopen() of a specific file would not be affected, only expelling the directory listing of the directory itself should be affected, not access to files therein. Still, I also noted the acl method as well which would be safer, more granular, and have zero effect on system services.
What are you going to accomplish by removing read permissions to those folders
They cannot write into them anyway.
The only folder i would worry about is tmp which they can delete 
drwxrwxrwt 265 root root 20480 May 5 12:45 tmp
You should try to inform yourself about the meaning of te t-bit.
Thanks for indicating the ‘t’. I realise i once deleted it from root user 
and not from normal user mode.
Normally (without the t-bit set on the directory) files can be deleted if the directory holding the files is writable for the person deleting files. Thus if you have a directory where anybody can deposit files then also anybody can delete the files of everybody else.
On 2013-05-05 05:06, LewsTherinTelemon wrote:
> I’d argue its not quite that clear cut that “this breaks the system as
> not all things run as root” - which of course I never said they did. A
> system service will a) run either as root, apache, mysqld, etc. b) will
> not require “other” read access referencing / (unless you can give an
> example where this is not true?) and d) any syscall to access or
> fopen() of a specific file would not be affected, only expelling the
> directory listing of the directory itself should be affected, not access
> to files therein. Still, I also noted the acl method as well which would
> be safer, more granular, and have zero effect on system services.
It is not an experiment I’m interested in testing 
AFAIK, changing the system permissions is dangerous, and that is enough
knowledge for me. More, is for the person interested in the experiment.
And that person, if he has any later problem, related or not, and he ask
for help in forums, should tell the people of that customization.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
While I was researching something else,
I happened to come upon what I think is the solution to your problem.
Surprisingly, when I started nosing around in the “new” YAST in 12.3, AppArmor has disappeared (but apparently still can be invoked, don’t know if it’s actually the foundation for the following).
Take a look in
YAST > Security and Users > Security Center and Hardening
It looks like there are some really cool new options which restrict non-privileged Users from seeing anything outside their (or a specified) directory root.
By default the File Permissions policy is still “Easy” which permits a User to see everything although may still be restricted from writing and executing. Try the “Secure” policy template, I doubt the “Paranoid” would be useful except maybe when all non-root Users log in remotely (all guesses). Of course read up on the related documentation and “Help” button to learn more about these options.
HTH,
TSU
On 2013-05-06 19:16, tsu2 wrote:
> Surprisingly, when I started nosing around in the “new” YAST in 12.3,
> AppArmor has disappeared (but apparently still can be invoked, don’t
> know if it’s actually the foundation for the following).
No, apparmour has to be installed by selecting its pattern.
> By default the File Permissions policy is still “Easy” which permits a
> User to see everything although may still be restricted from writing and
> executing. Try the “Secure” policy template, I doubt the “Paranoid”
> would be useful except maybe when all non-root Users log in remotely
> (all guesses). Of course read up on the related documentation and “Help”
> button to learn more about these options.
Be careful that “secure” settings can make a lot of things to stop
working. You have to find out what and solve them…
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)