• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1] 2
Author Topic: ACLs in kernel 2.6.22.18 ?  (Read 4023 times)
guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« on: September 20, 2009, 11:24:04 AM »

I would like to create a shared directory where users will have access to all files in read and write mode, even if the file has been created by another user.
To do this, I think the ACLs is the good thing, but the command setfacl does not work, with a Operation not supported error.

Is ACL option set in this kernel ? Is it in the newer kernel ? What is the best way to do what I want ?
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #1 on: September 20, 2009, 11:38:29 AM »

Like /tmp but without the sticky bit set?

It's not clear to me what a mode 777 directory will not do that you want...

Rgds

Damon
Logged

guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« Reply #2 on: September 20, 2009, 11:45:11 AM »

No, acls are not working with 777 rights, and with the 777 it won't work. Imagine user user1 create file test
This file will be owned by user1
user2 won't have rigths to modify file test ;-)
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 440


View Profile WWW
« Reply #3 on: September 20, 2009, 12:11:42 PM »

No, acls are not working with 777 rights, and with the 777 it won't work. Imagine user user1 create file test
This file will be owned by user1
user2 won't have rigths to modify file test ;-)
They will if the file has a 777 mode.  But this isn't related to the mode on the directory - it's related to the umask set for the process creating the file.
So, if you have control over the application used to modify the files you could try setting a umask of 0 for the processes concerned (an interlude shell script, for instance).
« Last Edit: September 20, 2009, 12:14:49 PM by birdman » Logged

guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« Reply #4 on: September 20, 2009, 12:21:12 PM »

It won't work ! I may create a file through ssh in vim, or copy a video file, anything, any time !
The proper solution I found is acls. I mounter the partition with acls enabled, and no errors appeared, but setting the acls to the directory I want to be public is not working (setfactl)
This might be due to no ACL support in the base kernel. But I don't know how to check this...
Logged

SgtPepper
Newbie
*

Karma: 2
Posts: 19


View Profile
« Reply #5 on: September 20, 2009, 12:49:04 PM »

Can't you just set the setgid bit in the directory permissions, and add all the users to a common group (that is the group owner of the directory)?

Then, all of the files created will have the same group ownership as the directory, and all of the members of that group will have access.
Logged

restamp
Global Moderator
Sr. Member
*****

Karma: 4
Posts: 273


View Profile
« Reply #6 on: September 20, 2009, 03:13:53 PM »

Since you're using the original kernel, my guess is that you're using the original NAND-based jffs2 file system.  I honestly don't know, but it would not surprise me to learn that jffs2 doesn't support ACLs.  (Does anyone know?)  This may be why you are seeing the setfacl errors.

That said, I think that, rather than ACLs, what you need is a way to make all files created in the shared directory mode 0666.  I don't know of any directory specification that will do this trick, but you could use wrapper scripts or a cron job to do this.  The real problem is making sure the file is created with the right mode.

Good luck.
Logged

guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« Reply #7 on: September 21, 2009, 05:14:54 AM »

I am using the original kernel, but my partition I want to share is in ext3, on an external HDD. I tried specifying setgid bit to the directory, like chmod g+s <group> but it does not work (maybe a umask problem ?). Creating a file with a user make this file not being writable for others...

I mounted the partition in fstab like this : /dev/sda4 /home defaults 0 0
Making a cron job to set permissions periodically is _ugly_ solution ;-)

Does anyone have some ideas ?
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #8 on: September 21, 2009, 07:35:32 AM »

A silly one first: did you run the chmod g+s as root?

Rgds

Damon
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 440


View Profile WWW
« Reply #9 on: September 21, 2009, 04:12:51 PM »

I tried specifying setgid bit to the directory, like chmod g+s <group> but it does not work (maybe a umask problem ?). Creating a file with a user make this file not being writable for others...
The process would need a umask of 002 (well 00x) to make it writeable/executable by group.  You can't force permission bits to be set on new objects by setting permission bits on a directory.
Logged

guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« Reply #10 on: September 21, 2009, 04:20:37 PM »

Here is the line dedicated to this partition :

/dev/sda4 /home ext3 defaults,umask=002 0 0

mount -a
mount: wrong fs type, bad option, bad superblock on /dev/sda4,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

If I remove ,umask=002, mounting works... What is wrong with umask=002 ?? It can't be on a /home mount ?
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #11 on: September 21, 2009, 11:20:46 PM »

Another silly question: not all filesystems support the umask= flag on mount; are you using it with an appropriate filesystem type (eg FAT, NTFS)?

Rgds

Damon
Logged

guepe
Newbie
*

Karma: 0
Posts: 10


View Profile
« Reply #12 on: September 22, 2009, 06:35:43 AM »

I thought ext3 was supporting it. Do you know a solution on ext3 ?
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #13 on: September 22, 2009, 09:13:28 AM »

I only brought this up because "man mount" suggested that your (latest) difficulty might be ext3 not supporting umask!  I don't have any new suggestions at the moment, other than those above.

Traditionally a common solution for this kind of issue (eg for RCS and CVS repositories accessed through the filesystem) has indeed been as suggested before in theis thread to put everyone concerned into a common group, give the target directory that group, and make it setgid.  Fairly reliable and no ACLs needed (I've been using that tecnique for getting on for 15 years on *nix).

Rgds

Damon
Logged

birdman
Sr. Member
****

Karma: 4
Posts: 440


View Profile WWW
« Reply #14 on: September 22, 2009, 03:48:24 PM »

Since ext3 is a standard Linux file system you can't specify umask as an option for it.  The option is only there for things such as FAT, which don't have a permission mask, UDF, where you might want to change things - etc.
Logged

Pages: [1] 2
Print
Jump to: