Hi: I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions: anyuser:users rwxrwxr-x at all times. That is, I want all users able to read, write, create, and destroy these files at will. I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask. How can I make the filesystem have a umask that overrides the users' umasks? Thanks for input. -- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
Chris Carlen wrote:
Hi:
I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions:
anyuser:users rwxrwxr-x
at all times.
That is, I want all users able to read, write, create, and destroy these files at will.
I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask.
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I think this is one of those rare cases where VMS would be easier! -- Jim Sabatke Hire Me!! - See my resume at http://my.execpc.com/~jsabatke Do not meddle in the affairs of Dragons, for you are crunchy and good with ketchup. NOTE: Please do not email me any attachments with Microsoft extensions. They are deleted on my ISP's server before I ever see them, and no bounce message is sent.
On Sunday 05 September 2004 06:34, Jim Sabatke wrote:
Chris Carlen wrote:
Hi:
I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions:
anyuser:users rwxrwxr-x
at all times.
That is, I want all users able to read, write, create, and destroy these files at will.
I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask.
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I think this is one of those rare cases where VMS would be easier!
Huh? I don't understand this - but everything is easy if one knows how to do it. The default umask is set in /etc/profile. Leave this file alone, additions go into /etc/profile.local (read the comments in that file). If you want a specific umask for a specific group, put the next lines in /etc/profile.local: if [ "`id -gn`" = "users" ]; then umask u=rwx,g=rwx,o=rx fi I did not test the if ... then construct, but I do have a umask definition in my profile.local that works. Cheers, Leen
Leen, On Sunday 05 September 2004 01:25, Leendert Meyer wrote:
On Sunday 05 September 2004 06:34, Jim Sabatke wrote:
Chris Carlen wrote:
Hi:
...
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I think this is one of those rare cases where VMS would be easier!
Huh? I don't understand this - but everything is easy if one knows how to do it.
But not everything is possible. The way I understood the request, Chris wants to have files that get created within a specific directory or set of directories to reflect a umask independent of that in effect in the process that does the creation. He's not trying to control each user's umask. Nor can he, of course--the best that can be done is to control the default or initial value, as your suggestion addresses. I know of no way to make happen what Chris wants. ... Actually, he said this was a separate file system. If the permissions required are lax, perhaps using a FAT file system would produce the desired results, or something close to them.
...
Cheers,
Leen
Randall Schulz
Randall R Schulz wrote:
<SNIP>
But not everything is possible.
The way I understood the request, Chris wants to have files that get created within a specific directory or set of directories to reflect a umask independent of that in effect in the process that does the creation. He's not trying to control each user's umask. Nor can he, of course--the best that can be done is to control the default or initial value, as your suggestion addresses.
I know of no way to make happen what Chris wants.
...
Actually, he said this was a separate file system. If the permissions required are lax, perhaps using a FAT file system would produce the desired results, or something close to them.
ACLs will do what he wants. Check out appendix B in the Administration Guide (assuming 9.1 here). From the parent directory type ... # setfacl -d -m group:yourgroup:rwx yourdirectory HTH Louis
Louis, On Sunday 05 September 2004 15:18, Louis Richards wrote:
Randall R Schulz wrote:
...
ACLs will do what he wants. Check out appendix B in the Administration Guide (assuming 9.1 here).
Wow. I didn't know this was a stock feature in Linux. The manual pages say nothing (that I've been able to find) about which file system support ACLs. Do they all? All the "native" formats, anyway?
From the parent directory type ...
# setfacl -d -m group:yourgroup:rwx yourdirectory
HTH Louis
Randall Schulz
Randall R Schulz wrote:
Louis,
On Sunday 05 September 2004 15:18, Louis Richards wrote:
Randall R Schulz wrote:
...
ACLs will do what he wants. Check out appendix B in the Administration Guide (assuming 9.1 here).
Wow. I didn't know this was a stock feature in Linux.
The manual pages say nothing (that I've been able to find) about which file system support ACLs. Do they all? All the "native" formats, anyway?
I've been playing with this for a while now. It seems to work OK locally, but it will lose the umask when used over NFS. I came over from RedHat which used a default umask of 002 and private groups for each user. This made it easy to do what the OP wanted. Just ... # chgrp mygroup mydirectory # chmod g+s mydirectory With the default umask of 002, this would work. I also added the "inherit permissions" line to my Samba shares. This also worked for my Windows clients. I have to be honest here. My default umask has been changed in /etc/profile.local to 002. I would like to change that back, but until I find a way to get NFS to honor the ACL set umask, I'll stick with what I know. HTH, Louis
Louis Richards wrote:
I came over from RedHat which used a default umask of 002 and private groups for each user. This made it easy to do what the OP wanted. Just ...
# chgrp mygroup mydirectory # chmod g+s mydirectory
With the default umask of 002, this would work. I also added the "inherit permissions" line to my Samba shares. This also worked for my Windows clients.
I have to be honest here. My default umask has been changed in /etc/profile.local to 002. I would like to change that back, but until I find a way to get NFS to honor the ACL set umask, I'll stick with what I know.
Thanks for the input. This offers hope of solving my problem. I have changed my users to their own private groups, and kept them members of the common group "users." The /photos dir has perms rwxrwsr-x root users so now my wife and I can create dirs and files in /photos, and the created files/dirs belong to group users thanks to the suid bit. Finally, I added a line umask 002 to /etc/profile.local, so we create all files and dirs with rwxrwxr-x (x only for dirs of course) The key here is that since we are in our own private groups, any files and dirs created within our own homes, are only writeable by use because of the private groups. This is important! I did NOT want to simply change our umasks and allow all users group members to be writable to each other. Not that we aren't open about our files, but keeping the security avoids accidental deletion of the other person's files. So everything is exactly what I want! There is one remaining problem. KDE's Konqueror doesn't obey the umask! It still creates files with 022 umask. What to do about this? Good day! -- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
Chris Carlen writes:
There is one remaining problem. KDE's Konqueror doesn't obey the umask! It still creates files with 022 umask.
Have you tried logging out of KDE completely and logging in again? When you start konqueror from your desktop it inherits the umask from the original shell that ran the KDE startup script. If you add a umask to /etc/profile.local, the current KDE environment does not "see" the change until you log out and log in again. -Ti
Ti Kan wrote:
Chris Carlen writes:
There is one remaining problem. KDE's Konqueror doesn't obey the umask! It still creates files with 022 umask.
Have you tried logging out of KDE completely and logging in again? When you start konqueror from your desktop it inherits the umask from the original shell that ran the KDE startup script. If you add a umask to /etc/profile.local, the current KDE environment does not "see" the change until you log out and log in again.
-Ti
I thought Konqueror used templates. You would need to change permissions on the template files. Look at /opt/kde3/share/templates/ HTH, Louis
Louis Richards wrote:
Ti Kan wrote:
Chris Carlen writes:
There is one remaining problem. KDE's Konqueror doesn't obey the umask! It still creates files with 022 umask.
Have you tried logging out of KDE completely and logging in again? When you start konqueror from your desktop it inherits the umask from the original shell that ran the KDE startup script. If you add a umask to /etc/profile.local, the current KDE environment does not "see" the change until you log out and log in again.
-Ti
I thought Konqueror used templates. You would need to change permissions on the template files.
Look at /opt/kde3/share/templates/
Why does Konq. create new dirs which agree with my umask, rwxrwxr-x but text files with rw-r--r-- ? Thanks. -- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
Chris Carlen wrote:
Louis Richards wrote:
Ti Kan wrote:
Chris Carlen writes:
There is one remaining problem. KDE's Konqueror doesn't obey the umask! It still creates files with 022 umask.
Have you tried logging out of KDE completely and logging in again? When you start konqueror from your desktop it inherits the umask from the original shell that ran the KDE startup script. If you add a umask to /etc/profile.local, the current KDE environment does not "see" the change until you log out and log in again.
-Ti
I thought Konqueror used templates. You would need to change permissions on the template files.
Look at /opt/kde3/share/templates/
Why does Konq. create new dirs which agree with my umask, rwxrwxr-x but text files with rw-r--r-- ?
Thanks.
Change permissions on the following files: # chmod g+w /opt/kde3/share/templates/.source/emptydir # chmod g+w /opt/kde3/share/templates/.source/TextFile.txt # chmod g+w /opt/kde3/share/templates/.source/HTMLFile.html HTH, Louis
Randall R Schulz wrote:
Louis,
On Sunday 05 September 2004 15:18, Louis Richards wrote:
Randall R Schulz wrote:
...
ACLs will do what he wants. Check out appendix B in the Administration Guide (assuming 9.1 here).
Wow. I didn't know this was a stock feature in Linux.
I think it's a newer feature to the *NIX filesystems. That's why I made an attempt at a joke about VMS, which had pretty sophisticated ACL control. I'm glad Linux is picking this stuff up. -- Jim Sabatke Hire Me!! - See my resume at http://my.execpc.com/~jsabatke Do not meddle in the affairs of Dragons, for you are crunchy and good with ketchup. NOTE: Please do not email me any attachments with Microsoft extensions. They are deleted on my ISP's server before I ever see them, and no bounce message is sent.
Randall R Schulz wrote:
Louis,
On Sunday 05 September 2004 15:18, Louis Richards wrote:
Randall R Schulz wrote:
...
ACLs will do what he wants. Check out appendix B in the Administration Guide (assuming 9.1 here).
Wow. I didn't know this was a stock feature in Linux.
A hint is provided by the mysterious "acl" options in the /etc/fstab. I began reading about it last night, but couldn't figure out how to make changes to the settings.
The manual pages say nothing (that I've been able to find) about which file system support ACLs. Do they all? All the "native" formats, anyway?
From the parent directory type ...
# setfacl -d -m group:yourgroup:rwx yourdirectory
HTH Louis
Randall Schulz
-- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
Randall R Schulz wrote:
Leen,
On Sunday 05 September 2004 01:25, Leendert Meyer wrote:
On Sunday 05 September 2004 06:34, Jim Sabatke wrote:
Chris Carlen wrote:
Hi:
...
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I think this is one of those rare cases where VMS would be easier!
Huh? I don't understand this - but everything is easy if one knows how to do it.
But not everything is possible.
The way I understood the request, Chris wants to have files that get created within a specific directory or set of directories to reflect a umask independent of that in effect in the process that does the creation. He's not trying to control each user's umask. Nor can he, of course--the best that can be done is to control the default or initial value, as your suggestion addresses.
I know of no way to make happen what Chris wants.
...
Actually, he said this was a separate file system. If the permissions required are lax, perhaps using a FAT file system would produce the desired results, or something close to them.
Thanks for the input. Unfortunately, I was using VFAT, but I couldn't get it to share over NFS without having to mount it explicitly on the client, because I think I had used the nohide option incorrectly. So I went and reformatted it to reiserfs. Now I figured out how to get it to share properly, and I'm pondering if I should go back to VFAT. :-( Good day! -- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
On Sunday 05 September 2004 10:25, Leendert Meyer wrote:
On Sunday 05 September 2004 06:34, Jim Sabatke wrote:
Chris Carlen wrote:
Hi:
I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions:
anyuser:users rwxrwxr-x
at all times.
That is, I want all users able to read, write, create, and destroy these files at will.
I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask.
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I think this is one of those rare cases where VMS would be easier!
Huh? I don't understand this - but everything is easy if one knows how to do it.
The default umask is set in /etc/profile. Leave this file alone, additions go into /etc/profile.local (read the comments in that file).
If you want a specific umask for a specific group, put the next lines in /etc/profile.local:
if [ "`id -gn`" = "users" ]; then umask u=rwx,g=rwx,o=rx fi
I did not test the if ... then construct, but I do have a umask definition in my profile.local that works.
One way to solve this would be to write a small program that uses fam, the file alteration monitor, to watch for new files being created and execute the chmod as and when it's needed. I don't know if something like this already exists, but if someone wants to try this, let me know
On Sunday 05 September 2004 16:46, Anders Johansson wrote:
One way to solve this would be to write a small program that uses fam, the file alteration monitor, to watch for new files being created and execute the chmod as and when it's needed. I don't know if something like this already exists, but if someone wants to try this, let me know
Out of boredom I actually went and wrote this :) Nothing fancy, much can be improved, perhaps it's not even needed but it was fun to try, fam is a really powerful tool. Comments are welcome ftp://rydsbo.net/pub/dirmon.c use -lfam to compile, needs fam-devel, start the fam daemon (rcfam start) before running the program
Leendert Meyer wrote:
On Sunday 05 September 2004 06:34, Jim Sabatke wrote:
Thanks for input.
I think this is one of those rare cases where VMS would be easier!
Huh? I don't understand this - but everything is easy if one knows how to do it.
It was really a feeble attempt at humor. I hated VMS with a passion. -- Jim Sabatke Hire Me!! - See my resume at http://my.execpc.com/~jsabatke Do not meddle in the affairs of Dragons, for you are crunchy and good with ketchup. NOTE: Please do not email me any attachments with Microsoft extensions. They are deleted on my ISP's server before I ever see them, and no bounce message is sent.
Chris Carlen wrote:
Hi:
I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions:
anyuser:users rwxrwxr-x
at all times.
That is, I want all users able to read, write, create, and destroy these files at will.
I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask.
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I see a much easier way - I don't remember exaclty the name, but is somewhat like sticky bit I was preparing a cvs directory, which some people would access locally. The solution was to use like a chmod 775 directory chgrp yyyyyyy directory (every one with access should belong to group yyyyyyyy) chmod g+s directory Now, every file created inside this directory will be created using the same permission from this one... (Hey, don't remeber it very well, it was done in March/April - may be wrote something wrong) Works very well; in my machine: lazarini@xxxxx:/interno> ll drwxrws--- 4 root cvs 96 2004-04-08 12:23 cvsroot What I remember very well is that the chmod man page is *very* poor about this feature; learned from a very good book "Linux administratoin handbook" - really recomend it. If needed, I can try to OCR the book's page. -- Marcos Lazarini
Marcos Lazarini wrote:
Chris Carlen wrote:
Hi:
I have a filesystem called /photos whose files and subdirs I want in group "users" and with permissions:
anyuser:users rwxrwxr-x
at all times.
That is, I want all users able to read, write, create, and destroy these files at will.
I can do this with recursive commands to change the perms, but when a user creates a new file, it is created with that user's umask.
How can I make the filesystem have a umask that overrides the users' umasks?
Thanks for input.
I see a much easier way - I don't remember exaclty the name, but is somewhat like sticky bit
I was preparing a cvs directory, which some people would access locally. The solution was to use like a chmod 775 directory chgrp yyyyyyy directory (every one with access should belong to group yyyyyyyy) chmod g+s directory
Now, every file created inside this directory will be created using the same permission from this one... (Hey, don't remeber it very well, it was done in March/April - may be wrote something wrong) Works very well; in my machine:
lazarini@xxxxx:/interno> ll drwxrws--- 4 root cvs 96 2004-04-08 12:23 cvsroot
What I remember very well is that the chmod man page is *very* poor about this feature; learned from a very good book "Linux administratoin handbook" - really recomend it. If needed, I can try to OCR the book's page.
Hi, thanks for the input. I'm not sure I follow you. I tried this, and the results appear inconsistent with what I think you mean: user1@ngong:~/dir1> touch file1 user1@ngong:~/dir1> l total 3 drwxrwsr-x 2 user1 users 72 2004-09-06 19:13 ./ drwxr-xr-x 71 user1 users 3240 2004-09-06 19:05 ../ -rw-r--r-- 1 user1 users 0 2004-09-06 19:13 file1 Notice that the directory ./ (the current directory) has the group 's' permission set. But when I create a file in this directory, it doesn't automatically get the group writable permission. Rather it gets the persmissions consistent with my umask of 022. Furthermore the man page for chmod indicates: STICKY DIRECTORIES When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. I don't think this is the thing we want to solve my problem. We really want some way of making the created files in a directory inherit the permissions of the directory, overriding the umask of the user. As some other respondents have suggested, access control lists might work, but this situation is complicated by the fact that the directory of interest is an NFS share. I'd have to experiment and see what happens. Still wishing for an easy answer... Good day! -- _____________________ Christopher R. Carlen crobc@earthlink.net SuSE 9.1 Linux 2.6.5
Chris Carlen wrote: <SNIP>
Hi, thanks for the input.
I'm not sure I follow you. I tried this, and the results appear inconsistent with what I think you mean:
user1@ngong:~/dir1> touch file1 user1@ngong:~/dir1> l total 3 drwxrwsr-x 2 user1 users 72 2004-09-06 19:13 ./ drwxr-xr-x 71 user1 users 3240 2004-09-06 19:05 ../ -rw-r--r-- 1 user1 users 0 2004-09-06 19:13 file1
Notice that the directory ./ (the current directory) has the group 's' permission set. But when I create a file in this directory, it doesn't automatically get the group writable permission. Rather it gets the persmissions consistent with my umask of 022.
Furthermore the man page for chmod indicates:
STICKY DIRECTORIES When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable.
I don't think this is the thing we want to solve my problem.
We really want some way of making the created files in a directory inherit the permissions of the directory, overriding the umask of the user.
As some other respondents have suggested, access control lists might work, but this situation is complicated by the fact that the directory of interest is an NFS share. I'd have to experiment and see what happens. Still wishing for an easy answer...
Good day!
The above isn't setting the sticky bit. That is setting the group id. This would work if the umask was 002. The only downside I can see from changing the default umask is the current permissions on the home directories. That can easily be changed to 700. This is what I have done and I have many shared directories working in the way you want both through NFS and Samba as well as locally. You can actually get pretty fancy with this setup. On one machine I have a public folder that all users can write to. It contains a restricted folder that everyone can read but only restricted can write. This folder then contains the secret folder that only restricted users can enter. This is then a single NFS and/or Samba share. drwxrwsr-x 4 root restricted 4096 Sep 1 17:14 . drwxrwsr-x 6 root users 4096 May 27 15:16 .. -rw-rw-r-- 1 ben restricted 333831 Sep 1 16:54 logo1.eps -rw-rw-r-- 1 ben restricted 111045 Sep 1 16:54 logo.eps -rw-rw-r-- 1 louis restricted 10367748 Sep 1 17:11 logo.tiff drwxrwsr-x 2 louis restricted 4096 May 27 15:09 New Folder -rw-rw-r-- 1 ben restricted 13899 Sep 1 17:14 SCLogo.gif drwxrws--- 2 louis restricted 4096 Sep 1 17:11 Secret The above would be shared in Samba as: [public] comment = Public Share path = /mnt/storage/public write list = @users inherit permissions = Yes map archive = No The "inherit permissions" requires the "map archive = no" and is what makes this work as expected. I would still prefer to use the inherited permissions available through ACLs though. HTH, Louis
participants (8)
-
Anders Johansson -
Chris Carlen -
Jim Sabatke -
Leendert Meyer -
Louis Richards -
Marcos Lazarini -
Randall R Schulz -
ti＠amb.org