[gentoo-user] local shared directory

[gentoo-user] local shared directory

[hw]

Hi,

how can I make it so that multiple users on a system who create
files in a local, shared directory do have write access to files
created by other users within the shared directory?

The directory is group-writeable, and the users belong to the group
which owns the directory.  This enables them to create files within
the shared directory, yet the files they create belong to the user
who created it, and other users cannot modify them.  The sticky bit
is set so that the files are owned by user:common-group.

I would like to avoid changing the umask.  If that cannot be avoided,
how do I change it?  Users log in through x2goclient, and fvwm is
being executed on login.

Re: [gentoo-user] local shared directory

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

On Thu, 17 Mar 2016 18:19:21 +0100, hw wrote:

> how can I make it so that multiple users on a system who create
> files in a local, shared directory do have write access to files
> created by other users within the shared directory?

ACLs.


-- 
Neil Bothwick

And if you say "No", I shall be forced to shoot you.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: local shared directory

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:

> 
> On Thu, 17 Mar 2016 18:19:21 +0100, hw wrote:
> 
> > how can I make it so that multiple users on a system who create
> > files in a local, shared directory do have write access to files
> > created by other users within the shared directory?
> 
> ACLs.


Hmmmmm. Perhaps one of our most knowledgable folks would like to 
share how to setup git locally on this machine and use it's features
to 'skin the cat' vis a vis this problem. The more I learn about git
the more I realize it is boundless on creative usages, so I'd be
very surprise, if one of our smarter members does not know how to
do this with git.


The git advantage would be that if the work ever needs to span countries or
continents, it should be then be trivial to migrate the repo(s) to the
cloud, github or similar distributed/container environments.


curiously,
James

Re: [gentoo-user] local shared directory

[Alan McKinnon]

On 17/03/2016 19:19, hw wrote:
> 
> Hi,
> 
> how can I make it so that multiple users on a system who create
> files in a local, shared directory do have write access to files
> created by other users within the shared directory?
> 
> The directory is group-writeable, and the users belong to the group
> which owns the directory.  This enables them to create files within
> the shared directory, yet the files they create belong to the user
> who created it, and other users cannot modify them.  The sticky bit
> is set so that the files are owned by user:common-group.
> 
> I would like to avoid changing the umask.  If that cannot be avoided,
> how do I change it?  Users log in through x2goclient, and fvwm is
> being executed on login.
> 

Ooooooh, that's a horrible one, with no really obvious answer.

First, you cannot do it with just regular Unix permissions.

umask is just not viable either, as a) it's global and affects all files
a user creates and b) by definition umask is modifiable by the user
(it's a feature to help users out so they don't need to chmod every file
every time) and c) you can't stop them doing it (by design).

There is a way to do it with Posix ACLs, I figured it out once. It was
ugly. It was horrible. It was impossible to describe to someone else.
And it was invisible (you had to spot the tiny "+" in ls -al and know
what it means to know to look further.

The simplest way is to run chown -R g+w dir in a cron every few minutes.
This works but it's inelegant.

The best solution I have found yet is to use the inotify feature in the
kernel. It's an event framework and really neat: tell the kernel to
generate an event every time something specific happens on the
filesystem, and write a small listener that run chmod. There are many
examples in the man pages.

In your case, the area to monitor is the shared directory itself, and
the event to register is on_file_create and on_file_modify. The listener
is a small script that launches chmod g+w

Do read the man pages thoroughly, the above will become clearer. inotify
is an amazing tool, I wish it were more in common use.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] local shared directory

[Rich Freeman]

On Thu, Mar 17, 2016 at 4:59 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> umask is just not viable either, as a) it's global and affects all files
> a user creates and b) by definition umask is modifiable by the user
> (it's a feature to help users out so they don't need to chmod every file
> every time) and c) you can't stop them doing it (by design).

Actually, this is completely viable.  Just set the default umasks to
007, and create a new group for each user as their default group (and
don't have all their home directories be owned by some users group).
This is how this sort of situation was handled long before POSIX ACLs
became common, and I know that some distros behave this way by default
for this reason (this was the case in the distro I used right before I
switched to Gentoo).

If users chmod a file then tell them not to.  If you must, set up some
cron job to clean up after them.

But, you can of course do this with ACLs as well.  I haven't tried
setting those up personally.

-- 
Rich

Re: [gentoo-user] local shared directory

[Michael Orlitzky]

On 03/17/2016 06:38 PM, Rich Freeman wrote:
> On Thu, Mar 17, 2016 at 4:59 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
> Actually, this is completely viable...
> 
> If users chmod a file then tell them not to.  If you must, set up some
> cron job to clean up after them.
> 
> But, you can of course do this with ACLs as well.  I haven't tried
> setting those up personally.
> 

I missed the beginning of this thread, but I just caught up on the
archive. This has long been a pet peeve of mine. I don't think there's a
way to make it work *at all* on Linux, which is stupid, since every
somebody's-nephew can set it up in five minutes on a Windows server.

You can very easily come up with a situation that umasks, group
membership, and setgid can't handle. Suppose you want a public website
directory to be,

  * Writable by the client (their developers)
  * Writable by your web developers
  * Readable by the Apache user

You can't make Apache a member of the group that has write access, so
while I haven't been real careful, I don't think you can make that
extremely common situation work. Every law office
(attorney/paralegal/secretary) and small business needs something
similar and it just can't be done.

ACLs also won't work, because nobody ever made default ACLs do the right
thing. Everything in the "acl" directory should be rwx by the "apache"
user below (that's what the setfacl does):

  $ mkdir acl
  $ cd acl
  $ setfacl -d -m user:apache:rwx .

But, it's not! Just copy any file in, and see what happens:

  $ cp /etc/profile ./
  $ getfacl profile
  # file: profile
  # owner: mjo
  # group: mjo user::rw-
  user:apache:rwx        # effective:r--
  group::r-x             # effective:r--
  mask::r--
  other::r--

The write and execute bits are masked, so your website crashes, because
Apache can't write that file (or traverse it, if we did the same
experiment with a directory).

The problem above is that most common tools will do something braindead
in the presence of ACLs, and attempt to preserve the existing group
bits. Even though, when there are ACLs around, those group bits don't
signify group permissions.

To make ACLs do the right thing, you need to run
sys-apps/apply-default-acl on every file that the users create, so that
the default ACLs get applied by default (craaazzzyyy). You can do that
in a cron job like Alan suggested, or I've hacked tar, cp, mkdir, etc.
to run it automatically on all of our servers.

Why do I need to hack coreutils to share a directory between three
people? The ACL/coreutils people don't really see this as a problem.
They say, tell your paralegal to RTFM and set the permissions how he
wants them. (It will take you about a week to read the man pages for ACLs.)

Re: [gentoo-user] local shared directory

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

On Thu, 17 Mar 2016 18:38:56 -0400, Rich Freeman wrote:

> > umask is just not viable either, as a) it's global and affects all
> > files a user creates and b) by definition umask is modifiable by the
> > user (it's a feature to help users out so they don't need to chmod
> > every file every time) and c) you can't stop them doing it (by
> > design).  
> 
> Actually, this is completely viable.  Just set the default umasks to
> 007, and create a new group for each user as their default group (and
> don't have all their home directories be owned by some users group).
> This is how this sort of situation was handled long before POSIX ACLs
> became common, and I know that some distros behave this way by default
> for this reason (this was the case in the distro I used right before I
> switched to Gentoo).
> 
> If users chmod a file then tell them not to.  If you must, set up some
> cron job to clean up after them.
> 
> But, you can of course do this with ACLs as well.  I haven't tried
> setting those up personally.

I've done this with ACLs in the past, which is why I suggested it, but
it's a pain to set up if you haven't used them before. Alan's suggestion
of using inotify is probably simplest. Install incrond and put something
like this in a file in /etc/incron.d

/shared/dir IN_CREATE,IN_MODIFY chmod g+w $#


-- 
Neil Bothwick

Windows Error #56: Operator fell asleep while waiting.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] local shared directory

[hw]

Neil Bothwick schrieb:
> On Thu, 17 Mar 2016 18:38:56 -0400, Rich Freeman wrote:
>
>>> umask is just not viable either, as a) it's global and affects all
>>> files a user creates and b) by definition umask is modifiable by the
>>> user (it's a feature to help users out so they don't need to chmod
>>> every file every time) and c) you can't stop them doing it (by
>>> design).
>>
>> Actually, this is completely viable.  Just set the default umasks to
>> 007, and create a new group for each user as their default group (and
>> don't have all their home directories be owned by some users group).
>> This is how this sort of situation was handled long before POSIX ACLs
>> became common, and I know that some distros behave this way by default
>> for this reason (this was the case in the distro I used right before I
>> switched to Gentoo).
>>
>> If users chmod a file then tell them not to.  If you must, set up some
>> cron job to clean up after them.
>>
>> But, you can of course do this with ACLs as well.  I haven't tried
>> setting those up personally.
>
> I've done this with ACLs in the past, which is why I suggested it, but
> it's a pain to set up if you haven't used them before. Alan's suggestion
> of using inotify is probably simplest. Install incrond and put something
> like this in a file in /etc/incron.d
>
> /shared/dir IN_CREATE,IN_MODIFY chmod g+w $#
>
>

Thank you very much, I'll try to use incron for this.

Re: [gentoo-user] local shared directory

[hw]

Neil Bothwick schrieb:
> On Thu, 17 Mar 2016 18:38:56 -0400, Rich Freeman wrote:
>
>>> umask is just not viable either, as a) it's global and affects all
>>> files a user creates and b) by definition umask is modifiable by the
>>> user (it's a feature to help users out so they don't need to chmod
>>> every file every time) and c) you can't stop them doing it (by
>>> design).
>>
>> Actually, this is completely viable.  Just set the default umasks to
>> 007, and create a new group for each user as their default group (and
>> don't have all their home directories be owned by some users group).
>> This is how this sort of situation was handled long before POSIX ACLs
>> became common, and I know that some distros behave this way by default
>> for this reason (this was the case in the distro I used right before I
>> switched to Gentoo).
>>
>> If users chmod a file then tell them not to.  If you must, set up some
>> cron job to clean up after them.
>>
>> But, you can of course do this with ACLs as well.  I haven't tried
>> setting those up personally.
>
> I've done this with ACLs in the past, which is why I suggested it, but
> it's a pain to set up if you haven't used them before. Alan's suggestion
> of using inotify is probably simplest. Install incrond and put something
> like this in a file in /etc/incron.d
>
> /shared/dir IN_CREATE,IN_MODIFY chmod g+w $#
>
>

PS: How about subdirectories?  The users sharing the directory can 
create and delete them as well, and files within them; yet incron 
ignores what happens in subdirectories.

Using 'chmod -R g+w $#' isn't very appealing, and how safely does it 
handle file names?

how to share a directory tree with files in it with multiple users (Re: [gentoo-user] local shared directory)

[hw]

hw schrieb:
> Neil Bothwick schrieb:
>> On Thu, 17 Mar 2016 18:38:56 -0400, Rich Freeman wrote:
>>
>>>> umask is just not viable either, as a) it's global and affects all
>>>> files a user creates and b) by definition umask is modifiable by the
>>>> user (it's a feature to help users out so they don't need to chmod
>>>> every file every time) and c) you can't stop them doing it (by
>>>> design).
>>>
>>> Actually, this is completely viable.  Just set the default umasks to
>>> 007, and create a new group for each user as their default group (and
>>> don't have all their home directories be owned by some users group).
>>> This is how this sort of situation was handled long before POSIX ACLs
>>> became common, and I know that some distros behave this way by default
>>> for this reason (this was the case in the distro I used right before I
>>> switched to Gentoo).
>>>
>>> If users chmod a file then tell them not to.  If you must, set up some
>>> cron job to clean up after them.
>>>
>>> But, you can of course do this with ACLs as well.  I haven't tried
>>> setting those up personally.
>>
>> I've done this with ACLs in the past, which is why I suggested it, but
>> it's a pain to set up if you haven't used them before. Alan's suggestion
>> of using inotify is probably simplest. Install incrond and put something
>> like this in a file in /etc/incron.d
>>
>> /shared/dir IN_CREATE,IN_MODIFY chmod g+w $#
>>
>>
>
> PS: How about subdirectories?  The users sharing the directory can
> create and delete them as well, and files within them; yet incron
> ignores what happens in subdirectories.
>
> Using 'chmod -R g+w $#' isn't very appealing, and how safely does it
> handle file names?
>
>


PPS: Since it is impossible to share a local directory tree with 
multiple users, I'm trying to use a directory tree on a server, which is 
exported using samba and mounted by an entry in fstab.  (I could also 
use nfs, if it helps.)

That still doesn't work.  How do I calculate an appropriate 'create 
mask' for the smb.conf to at least force the files group writable?  I 
wouldn't even mind if all the files belonged to the same user.  Or what 
would I need to do?

Has it become entirely impossible to share a directory tree and the 
files in it with multiple users when Linux is involved?  This should be 
a very simple thing to accomplish.

Re: how to share a directory tree with files in it with multiple users (Re: [gentoo-user] local shared directory)

[Michael Orlitzky]

On 04/23/2016 10:42 AM, hw wrote:
> 
> Has it become entirely impossible to share a directory tree and the 
> files in it with multiple users when Linux is involved?  This should be 
> a very simple thing to accomplish.
> 

It was never possible. It's ridiculous, but there it is. The UNIX
permissions model is too simple. ACLs were bolted on top, but most tools
retain legacy behavior with respect to group masks that breaks default
ACLs. You're seeing that same problem with your Samba share.

Filesystem permissions are one thing that Windows got right. There's
ongoing work to bring that model to Linux,

  https://en.wikipedia.org/wiki/Richacls

but they're going to make the same mistake again[0] and allow the group
bits to act as a mask. That means mkdir, tar, cp, 7z -- anything that
tries to mess with group bits -- isn't going to work. They'll be DOA
just like POSIX ACLs were.

I think you can manage this with incron and POSIX ACLs. Instead of
running "chmod g+w", use sys-apps/apply-default-acl to reset the
permissions to the defaults that you set.

I wrote apply-default-acl to solve exactly this problem. You just need
to figure out a way to run it whenever things get screwed up. Which
means, whenever a file or directory is created.


[0] http://www.bestbits.at/richacl/man/richacl.7.txt

 Changing the file mode permission bits:

  When changing the file mode permission bits with chmod(1), the
  owner, group, and other file permission bits are set to the
  permission bits in the new mode... In addition, the masked and
  write_through ACL flags are set. This has the effect of limiting the
  permissions granted by the ACL to the file mode  permission bits...

Re: how to share a directory tree with files in it with multiple users (Re: [gentoo-user] local shared directory)

[hw]

Michael Orlitzky schrieb:
> On 04/23/2016 10:42 AM, hw wrote:
>>
>> Has it become entirely impossible to share a directory tree and the
>> files in it with multiple users when Linux is involved?  This should be
>> a very simple thing to accomplish.
>>
>
> It was never possible. It's ridiculous, but there it is. The UNIX
> permissions model is too simple. ACLs were bolted on top, but most tools
> retain legacy behavior with respect to group masks that breaks default
> ACLs. You're seeing that same problem with your Samba share.
>
> Filesystem permissions are one thing that Windows got right. There's
> ongoing work to bring that model to Linux,
>
>    https://en.wikipedia.org/wiki/Richacls
>
> but they're going to make the same mistake again[0] and allow the group
> bits to act as a mask. That means mkdir, tar, cp, 7z -- anything that
> tries to mess with group bits -- isn't going to work. They'll be DOA
> just like POSIX ACLs were.
>
> I think you can manage this with incron and POSIX ACLs. Instead of
> running "chmod g+w", use sys-apps/apply-default-acl to reset the
> permissions to the defaults that you set.
>
> I wrote apply-default-acl to solve exactly this problem. You just need
> to figure out a way to run it whenever things get screwed up. Which
> means, whenever a file or directory is created.
>
>
> [0] http://www.bestbits.at/richacl/man/richacl.7.txt
>
>   Changing the file mode permission bits:
>
>    When changing the file mode permission bits with chmod(1), the
>    owner, group, and other file permission bits are set to the
>    permission bits in the new mode... In addition, the masked and
>    write_through ACL flags are set. This has the effect of limiting the
>    permissions granted by the ACL to the file mode  permission bits...
>
>

Hm, I'm confused.  Is it not possible to somehow force
samba to set a user and a group as owners of a file or
of a directory which is being created on a share?

If that was possible, couldn't I mount that share with
the uid and gid of the owner and group samba enforces,
which would then allow multiple local users to access
the files and directories on that share as one?

Re: how to share a directory tree with files in it with multiple users (Re: [gentoo-user] local shared directory)

[Alan McKinnon]

On 07/05/2016 17:12, hw wrote:
> Michael Orlitzky schrieb:
>> On 04/23/2016 10:42 AM, hw wrote:
>>>
>>> Has it become entirely impossible to share a directory tree and the
>>> files in it with multiple users when Linux is involved?  This should be
>>> a very simple thing to accomplish.
>>>
>>
>> It was never possible. It's ridiculous, but there it is. The UNIX
>> permissions model is too simple. ACLs were bolted on top, but most tools
>> retain legacy behavior with respect to group masks that breaks default
>> ACLs. You're seeing that same problem with your Samba share.
>>
>> Filesystem permissions are one thing that Windows got right. There's
>> ongoing work to bring that model to Linux,
>>
>>    https://en.wikipedia.org/wiki/Richacls
>>
>> but they're going to make the same mistake again[0] and allow the group
>> bits to act as a mask. That means mkdir, tar, cp, 7z -- anything that
>> tries to mess with group bits -- isn't going to work. They'll be DOA
>> just like POSIX ACLs were.
>>
>> I think you can manage this with incron and POSIX ACLs. Instead of
>> running "chmod g+w", use sys-apps/apply-default-acl to reset the
>> permissions to the defaults that you set.
>>
>> I wrote apply-default-acl to solve exactly this problem. You just need
>> to figure out a way to run it whenever things get screwed up. Which
>> means, whenever a file or directory is created.
>>
>>
>> [0] http://www.bestbits.at/richacl/man/richacl.7.txt
>>
>>   Changing the file mode permission bits:
>>
>>    When changing the file mode permission bits with chmod(1), the
>>    owner, group, and other file permission bits are set to the
>>    permission bits in the new mode... In addition, the masked and
>>    write_through ACL flags are set. This has the effect of limiting the
>>    permissions granted by the ACL to the file mode  permission bits...
>>
>>
> 
> Hm, I'm confused.  Is it not possible to somehow force
> samba to set a user and a group as owners of a file or
> of a directory which is being created on a share?
> 
> If that was possible, couldn't I mount that share with
> the uid and gid of the owner and group samba enforces,
> which would then allow multiple local users to access
> the files and directories on that share as one?


Now you've added a whole new wrinkle that was never mentioned before -
samba. Yes, samba can enforce the permissions you want on file system
objects in shares it controls. To be accurate, it runs as root and
presents the perms you want to the user, but only when accessing the
files via samba. Look at these options in smb.conf

create mask = 664
force create mode = 664
security mask = 664
force security mode = 664
directory mask = 2775
force directory mode = 2775
directory security mask = 2775
force directory security mode = 2775

With this you can achieve what you want, but you have to ensure that
samba is the only way the users can access the files.

I'm assuming you completely and correctly understand umask.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

solved: how to share a directory tree with files in it with multiple users (Re: [gentoo-user] local shared directory)

[hw]

Alan McKinnon schrieb:
> On 07/05/2016 17:12, hw wrote:
>> Michael Orlitzky schrieb:
>>> On 04/23/2016 10:42 AM, hw wrote:
>>>>
>>>> Has it become entirely impossible to share a directory tree and the
>>>> files in it with multiple users when Linux is involved?  This should be
>>>> a very simple thing to accomplish.
>>>>
>>>
>>> It was never possible. It's ridiculous, but there it is. The UNIX
>>> permissions model is too simple. ACLs were bolted on top, but most tools
>>> retain legacy behavior with respect to group masks that breaks default
>>> ACLs. You're seeing that same problem with your Samba share.
>>>
>>> Filesystem permissions are one thing that Windows got right. There's
>>> ongoing work to bring that model to Linux,
>>>
>>>     https://en.wikipedia.org/wiki/Richacls
>>>
>>> but they're going to make the same mistake again[0] and allow the group
>>> bits to act as a mask. That means mkdir, tar, cp, 7z -- anything that
>>> tries to mess with group bits -- isn't going to work. They'll be DOA
>>> just like POSIX ACLs were.
>>>
>>> I think you can manage this with incron and POSIX ACLs. Instead of
>>> running "chmod g+w", use sys-apps/apply-default-acl to reset the
>>> permissions to the defaults that you set.
>>>
>>> I wrote apply-default-acl to solve exactly this problem. You just need
>>> to figure out a way to run it whenever things get screwed up. Which
>>> means, whenever a file or directory is created.
>>>
>>>
>>> [0] http://www.bestbits.at/richacl/man/richacl.7.txt
>>>
>>>    Changing the file mode permission bits:
>>>
>>>     When changing the file mode permission bits with chmod(1), the
>>>     owner, group, and other file permission bits are set to the
>>>     permission bits in the new mode... In addition, the masked and
>>>     write_through ACL flags are set. This has the effect of limiting the
>>>     permissions granted by the ACL to the file mode  permission bits...
>>>
>>>
>>
>> Hm, I'm confused.  Is it not possible to somehow force
>> samba to set a user and a group as owners of a file or
>> of a directory which is being created on a share?
>>
>> If that was possible, couldn't I mount that share with
>> the uid and gid of the owner and group samba enforces,
>> which would then allow multiple local users to access
>> the files and directories on that share as one?
>
>
> Now you've added a whole new wrinkle that was never mentioned before -
> samba. Yes, samba can enforce the permissions you want on file system
> objects in shares it controls. To be accurate, it runs as root and
> presents the perms you want to the user, but only when accessing the
> files via samba. Look at these options in smb.conf
>
> create mask = 664
> force create mode = 664
> security mask = 664
> force security mode = 664
> directory mask = 2775
> force directory mode = 2775
> directory security mask = 2775
> force directory security mode = 2775
>
> With this you can achieve what you want, but you have to ensure that
> samba is the only way the users can access the files.
>
> I'm assuming you completely and correctly understand umask.
>
>

Thank you very much!  This seems to work --- and it is what I had
in mind to begin with, yet looking at the samba documentation made
me think that 'force create mode' (or what it was) has been removed
from the options some time recently.

Re: [gentoo-user] local shared directory

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Sat, 23 Apr 2016 14:42:56 +0200, hw wrote:

> > I've done this with ACLs in the past, which is why I suggested it, but
> > it's a pain to set up if you haven't used them before. Alan's
> > suggestion of using inotify is probably simplest. Install incrond and
> > put something like this in a file in /etc/incron.d
> >
> > /shared/dir IN_CREATE,IN_MODIFY chmod g+w $#

That should actually be $@/$#

> PS: How about subdirectories?  The users sharing the directory can 
> create and delete them as well, and files within them; yet incron 
> ignores what happens in subdirectories.

That's a prpblem, maybe ACLs would be more suitable after all.

> Using 'chmod -R g+w $#' isn't very appealing, and how safely does it 
> handle file names?

What is unappealing about it? I've never had any problem with file names,
but I don't use odd ones. You could quote the $@/$# just in case,
although if there's no shell expansion taking place it shouldn't be
necessary.


-- 
Neil Bothwick

Hyperbole is absolutely the worst mistake you can possibly make

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] local shared directory

[hw]

Neil Bothwick schrieb:
> On Sat, 23 Apr 2016 14:42:56 +0200, hw wrote:
>
>>> I've done this with ACLs in the past, which is why I suggested it, but
>>> it's a pain to set up if you haven't used them before. Alan's
>>> suggestion of using inotify is probably simplest. Install incrond and
>>> put something like this in a file in /etc/incron.d
>>>
>>> /shared/dir IN_CREATE,IN_MODIFY chmod g+w $#
>
> That should actually be $@/$#

Thanks, that's what I used.

>> PS: How about subdirectories?  The users sharing the directory can
>> create and delete them as well, and files within them; yet incron
>> ignores what happens in subdirectories.
>
> That's a prpblem, maybe ACLs would be more suitable after all.
>
>> Using 'chmod -R g+w $#' isn't very appealing, and how safely does it
>> handle file names?
>
> What is unappealing about it? I've never had any problem with file names,
> but I don't use odd ones. You could quote the $@/$# just in case,
> although if there's no shell expansion taking place it shouldn't be
> necessary.

Using 'chmod -R' is unappealing because changing access rights for
so-many-thousand or so directory-entries once per minute might
wear out the SSDs sooner than otherwise.  It might make things
worse that the file system is that of a KVM VM residing in a sparse
file on these SSDs.

And it may lead to confusion of the users when they suddenly can
write to files they couldn't write to a few seconds before.

Re: [gentoo-user] local shared directory

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Sat, 14 May 2016 18:23:10 +0200, hw wrote:

> >> Using 'chmod -R g+w $#' isn't very appealing, and how safely does it
> >> handle file names?  
> >
> > What is unappealing about it? I've never had any problem with file
> > names, but I don't use odd ones. You could quote the $@/$# just in
> > case, although if there's no shell expansion taking place it
> > shouldn't be necessary.  
> 
> Using 'chmod -R' is unappealing because changing access rights for
> so-many-thousand or so directory-entries once per minute might

Why would you be running it every minute?

> wear out the SSDs sooner than otherwise.  It might make things
> worse that the file system is that of a KVM VM residing in a sparse
> file on these SSDs.
> 
> And it may lead to confusion of the users when they suddenly can
> write to files they couldn't write to a few seconds before.

Chmod is run when files are created or modified, and only on those files.
There is no timing involved, except for the fraction of a second it takes
for incrond to receive and act upon the inotify message.


-- 
Neil Bothwick

Politics: Poli (many) - tics (blood sucking parasites)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]