Autochown: inotify-based file attribute manager

Xyne · 2012-09-17 05:14:44

Info page: http://xyne.archlinux.ca/projects/autochown/

This is a direct successor to maown.

Autochown manages file ownership and permissions using inotify events. It is configured via a simple yet versatile input file. Examples of what you can do with it:
* ensure that all files in a given directory are owned by a certain group
* remove permissions for anyone not in the group
* change file owners automatically
* add exceptions for files, subdirectories, etc with globbing patterns

Eample scenarios in which it should be useful:
* keeping common files on a default user account that you want to access and modify from other user accounts
* ensuring that certain directories always retain strict file permissions
* managing a shared directory for group collaboration

Questions, comments, etc. are welcome as always.

SanskritFritz · 2012-09-19 19:37:54

Just what the doctor ordered, thank you! I think this will replace bindfs on my system here

Xyne · 2012-09-20 20:02:52

Thanks for the feedback.

What do you think of the input file syntax? I hesitated a while before deciding on the current format. Is it intuitive (after reading the documentation)?

kirk · 2012-12-23 21:14:41

Xyne,

I'm using another distro (Fatdog64). I compiled Autochown-2012.12. I'm wanting to run it as a daemon to chown everything that goes into a directory to the same user. My autochown.conf looks like this:

C]
> spot:spot::/root/spot/Downloads
]

When I try:

autochown -d /etc/autochownd.conf

It seems to start but doesn't seem to run as a daemon. Ps doesn't show it running and the pid isn't listed. I see in the autochownd script that it calls add_daemon from /etc/rc.d/functions. So I'm probably missing something from there. Anyway to start it as a daemon from a terminal?

Thanks,

Kirk

Xyne · 2012-12-24 00:26:49

Hi Kirk,

The autochownd script is a deprecated Arch Linux daemon and has no effect on the behavior of autochown. The source archive also includes an autochown service file for systemd, but that too has no effect on autochown itself. Both are just wrappers around autochown that use /etc/autochown.conf. If you are starting autochown manually then you could use a different configuration file.

Open up a terminal and run the following command:

autochown -v /etc/autochownd.conf

If it exits immediately with no output, check the exit status (echo $?). If it does not exit immediately, open another terminal and create a file in /root/spot/Downloads. Try chown'ing the file to a different user:group and check if it gets autochown'd back to spot:spot. You should see some output in the other terminal as well. Let me know what happens.

kirk · 2012-12-24 03:06:08

Sorry,

It was my fault. I added -Os to CMAKE_C_FLAGS and that broke it. Recompiled without that and it works.

One more Question, it doesn't seem to follow symlinks from the autochownd.conf file. With /root/spot/Downloads in autochownd.conf (which is actually a symlink to /aufs/devsave/Downloads) it doesn't work. But if I put the real path in it works fine. Any way around that? Other than using the real path We actually move that folder around depending on the installation.

Thanks again for this app. I think it might be quite useful for us. In Fatdog64 by default you're auto logged in as root, but network apps (browser, email, chat etc) run as a very restricted user (spot). We support also support a more traditional log in, but this is the preferred way.

Xyne · 2012-12-24 07:29:57

kirk wrote:

It was my fault. I added -Os to CMAKE_C_FLAGS and that broke it. Recompiled without that and it works.

Ah, good. I really had no idea why it wasn't working.

kirk wrote:

One more Question, it doesn't seem to follow symlinks from the autochownd.conf file. With /root/spot/Downloads in autochownd.conf (which is actually a symlink to /aufs/devsave/Downloads) it doesn't work. But if I put the real path in it works fine. Any way around that? Other than using the real path We actually move that folder around depending on the installation.

That's intentional. If it followed symlinks then any user with write access to a watched directory could create a symlink to anything on the system. It would also require more IO operations and sanity checks in the code. I recommend using a script to generate the configuration file if you do not know in advance where the directory will be.

kirk wrote:

Thanks again for this app. I think it might be quite useful for us. In Fatdog64 by default you're auto logged in as root, but network apps (browser, email, chat etc) run as a very restricted user (spot). We support also support a more traditional log in, but this is the preferred way.

I hope it does prove useful for you. It's also nice to see it being used outside of Arch.

kozaki · 2013-02-11 16:38:24

Autochown would fit our needs for shared directories, that bashrc 'umask' partially solved so far.
Thank you Xyne also for the nicely detailed man page and for adding the systemd unit!
Will test it ASAP.

Xyne · 2013-02-12 16:47:58

@kozaki
Thanks for the feedback. I hope that it proves useful for you. If you have any problems, let me know.

skanky · 2013-02-12 21:35:07

Was just wondering what to do about this very issue and stumbled upon this thread in the "new" search.

One comment - the service file passes in /etc/autochown.conf but the package (your repo) installs autochownd.conf.

Anyway only just set it up and it's working, so no other feedback except that it's simple to configure for basic setups.

Xyne · 2013-02-12 21:53:15

Thanks, the path has been updated. It seems that you are the first to use the service file.

skanky wrote:

it's simple to configure for basic setups.

My own usage is very simple (and that's what I wrote it for) but I'm hoping the globbing will enable more complicated setups without too much complexity. If you at some point find the configuration file to be limited, let me know.

skanky · 2013-02-12 21:57:51

Xyne wrote:

Thanks, the path has been updated. It seems that you are the first to use the service file.

I just thought the others were being coy.

Xyne wrote:

skanky wrote:
it's simple to configure for basic setups.
My own usage is very simple (and that's what I wrote it for) but I'm hoping the globbing will enable more complicated setups without too much complexity. If you at some point find the configuration file to be limited, let me know.

Actually, I have found one potential feature request. I can't see any way to apply different mask to files and directories (apologies if it's there, but it's late here and been a long day).
If there isn't, is it possible to add that? I'd like to disable the execution permission on all files (some of the time just mounting stuff as noexec gets round this, but there are situations where it would be nice, even if only for the colouring of file types in ls).

Last edited by skanky (2013-02-12 21:59:22)

Xyne · 2013-02-12 22:08:37

Do you mean that you want to have user-executable files that are non-executable for others, while still keeping directories executable for everyone?
E.g. the file mask would be 001 and the directory mask would be 000?

I have an idea that may be simple enough to implement to achieve that. If not, please give me a specific example.

skanky · 2013-02-12 22:13:53

For the situation I'm currently looking at, if I copy some files into the directory I want them to be 664, but I obviously want any new directories to be 775. Or is autochown clever enough to do that for me, in that it won't break a directory?

I c(sh)ould just have tested, I suppose.

Edit: I should mention that some files are coming from ntfs/vfat etc. so permissions tend to be 7xx. I'll look into how I can affect that in the morning (it's a subject I should get a proper handle on anyway), so no worries if it doesn't make sense or would be difficult to do.

Last edited by skanky (2013-02-12 22:19:41)

Xyne · 2013-02-12 22:19:57

Ha, I was just coming back to edit my post after getting what you meant as I read the man page.

I'm considering ways to implement masks per filetype. I'm not sure if I will though, because part of the philosophy of autochown is that the user mode bits are authoritative. That fact that the mask can reduce them is mostly a side-effect of the implementation.

Let me give it some thought. In the meantime, a simple "find /path/to/dir -type f -exec chmod -x '{}' \+" will do the trick.

skanky · 2013-02-12 22:25:41

Xyne wrote:

Ha, I was just coming back to edit my post after getting what you meant as I read the man page.
I'm considering ways to implement masks per filetype. I'm not sure if I will though, because part of the philosophy of autochown is that the user mode bits are authoritative. That fact that the mask can reduce them is mostly a side-effect of the implementation.
Let me give it some thought. In the meantime, a simple "find /path/to/dir -type f -exec chmod -x '{}' \+" will do the trick.

Yeah that's what I was using before. I was looking to automate it. However, this is useful even so as ownership and group writable were the biggest issues.
The executable flag is something that can be tidied up daily or maybe even weekly.

However I'll look into masks and stuff and mount time and the like anyway, as I really should do anyway. If I find a way to resolve it I'll post back here, but thanks for considering it and writing autochown anyway. As I say it's solved the main issues.

Xyne · 2013-02-13 05:09:19

I ended up spending a bit of time on autochown tonight once I had the idea in my head and ended up with a few new things:

You can now specify per-filetype masks on the target line. For example, to enforce non-executable files you can use this:

> nobody:users:002R113:/path/to/whatever

The default mask is then 002 and it behaves exactly as before. After that is the file mask for regular files (R113). Whenever a regular file is encountered it will use that mask instead (i.e. not on top) of the default mask. The effect is thus to deny others write permissions on everything and everyone execute permissions on files. The recognized filetype specifies are listed in the man page. The underlying code uses the GNU C filetype tests: http://www.gnu.org/software/libc/manual … -File-Type

Once I had that I thought it might be useful to be able to restrict the filetypes allowed in the watched directory. I ended up creating a killmask (700), i.e. a mask that indicates that a filetype should be removed. Given the potential damage that it could do, it requires a command-line option to be enabled. One of the nice side-effects of the inotify system is that recursive directory removal is handled automatically if the files in the directory are removed by killmasks. I may add some way to actively remove a non-empty directory to enforce a flat directory hierarchy, but that a little is dangerous.

You can reverse the logic too and set a default killmask and then only allow certain filetypes to be created, e.g. regular files. Due to the way inotify events arrive, it's still possible to create directories with other things in them that won't get purged, but after the events arrive the only thing left in those dirs will be regular files.

Finally I added a dry-run option when I realized that testing the killmask might be dangerous otherwise and i didn't feel like playing comment tag.

The code has been improved in several places as well (bug fixes, more robust handling of certain event notifications).

Check the man page for more info about the changes. Ask if you have any questions after that.

Last edited by Xyne (2013-02-13 05:13:11)

skanky · 2013-02-13 10:41:31

That looks ideal, many thanks for sorting that. I've applied the updated version, and will let it run for a little while to see how it goes. So far though it looks good.
Again, many thanks.

Xyne · 2013-02-13 19:51:48

The current version contains a bug that can mess with permissions of files outside of the directory if they are symlinked within the directory. I will post an update shortly but I need to reboot before I can do anything else.

kozaki · 2013-02-13 20:11:49

skanky wrote:

One comment - the service file passes in /etc/autochown.conf but the package (your repo) installs autochownd.conf.
Xyne wrote:
Thanks, the path has been updated. It seems that you are the first to use the service file.
I just thought the others were being coy.

Take me in Actually that would have been in my feedback. Well, is part of*

Xyne wrote:

skanky wrote:
it's simple to configure for basic setups.
My own usage is very simple (and that's what I wrote it for) but I'm hoping the globbing will enable more complicated setups without too much complexity. If you at some point find the configuration file to be limited, let me know.

Does the job instantly as wished here Day to day usage for users, and sync (e.g. no more Dropbox "Couldn't sync this and that") will be really smoother now. Thank you Xyne!

(*) autochown-2013.2.13 won't compile in this location:

[ 75%] Building C object CMakeFiles/autochown.dir/src/file_parser.c.o
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c: In function ‘scan’:
/tmp/yaourt-tmp-kozaki/aur-autochown/src/autochown-2013.2.13/src/main.c:364:7: attention : ‘return’ with a value, in function returning void [enabled by default]
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c: Hors de toute fonction :
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c:448:3: erreur: unknown type name ‘wd_key_data_t’
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c: In function ‘main’:
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c:726:44: erreur: ‘remove_all_watches’ undeclared (first use in this function)
/tmp/yaourt-xxxx/aur-autochown/src/autochown-2013.2.13/src/main.c:726:44: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [CMakeFiles/autochown.dir/src/main.c.o] Erreur 1
make[2]: *** Attente des tâches non terminées....
make[1]: *** [CMakeFiles/autochown.dir/all] Erreur 2
make: *** [all] Erreur 2
==> ERREUR : Une erreur s'est produite dans build().
    Abandon...
==> ERREUR: Makepkg n'a pas pu construire autochown.

Xyne · 2013-02-13 21:00:15

Ok, the new version is up. All mentioned bugs have been squashed.

To be clear, the latest version is 2013.2.13.1. If you are using 2013.*, upgrade immediately as there is a nasty bug in some of those.

Last edited by Xyne (2013-02-13 21:02:25)

kozaki · 2013-02-13 21:12:20

2013.2.13.1 compiled
Of course I like autochown let the symlinks out of the automation, just as you said before.

Xyne · 2013-02-13 23:24:08

Updated again. It now uses lchown.
Related discussion here: https://bbs.archlinux.org/viewtopic.php?id=158068

niski · 2013-04-25 13:07:43

I'm trying to set up autochown to monitor user permissions in apache's webroot. Right now I'm stuck with following error:

 error: failed to add watch (/srv/http/shop/lib/symfony/vendor/propel-generator/templates/sql/db-init/pgsql) [No space left on device]

the entry in /etc/autochownd.conf looks like this:

> http:http-pub::/srv/http

Any idea which of the devices is it referring to? df's output doesn't show anything suspicious. According to find, there are

find . -type d | wc -l                                                                                                                                       
18490

directories and

find . -type f | wc -l                                                                                                                                                 
57674

files in /srv/http

Last edited by niski (2013-04-25 13:08:06)

falconindy · 2013-04-25 13:13:09

niski wrote:

I'm trying to set up autochown to monitor user permissions in apache's webroot. Right now I'm stuck with following error:
 error: failed to add watch (/srv/http/shop/lib/symfony/vendor/propel-generator/templates/sql/db-init/pgsql) [No space left on device] 

inotify_add_watch returns ENOSPC when, to quote the manpage: "The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource.". You can modify this value by writing to /proc/sys/fs/inotify/max_user_watches, but there is a hard limit, and every watch consumes kernel resources.

Arch Linux

#1 2012-09-17 05:14:44

Autochown: inotify-based file attribute manager

#2 2012-09-19 19:37:54

Re: Autochown: inotify-based file attribute manager

#3 2012-09-20 20:02:52

Re: Autochown: inotify-based file attribute manager

#4 2012-12-23 21:14:41

Re: Autochown: inotify-based file attribute manager

#5 2012-12-24 00:26:49

Re: Autochown: inotify-based file attribute manager

#6 2012-12-24 03:06:08

Re: Autochown: inotify-based file attribute manager

#7 2012-12-24 07:29:57

Re: Autochown: inotify-based file attribute manager

#8 2013-02-11 16:38:24

Re: Autochown: inotify-based file attribute manager

#9 2013-02-12 16:47:58

Re: Autochown: inotify-based file attribute manager

#10 2013-02-12 21:35:07

Re: Autochown: inotify-based file attribute manager

#11 2013-02-12 21:53:15

Re: Autochown: inotify-based file attribute manager

#12 2013-02-12 21:57:51

Re: Autochown: inotify-based file attribute manager

#13 2013-02-12 22:08:37

Re: Autochown: inotify-based file attribute manager

#14 2013-02-12 22:13:53

Re: Autochown: inotify-based file attribute manager

#15 2013-02-12 22:19:57

Re: Autochown: inotify-based file attribute manager

#16 2013-02-12 22:25:41

Re: Autochown: inotify-based file attribute manager

#17 2013-02-13 05:09:19

Re: Autochown: inotify-based file attribute manager

#18 2013-02-13 10:41:31

Re: Autochown: inotify-based file attribute manager

#19 2013-02-13 19:51:48

Re: Autochown: inotify-based file attribute manager

#20 2013-02-13 20:11:49

Re: Autochown: inotify-based file attribute manager

#21 2013-02-13 21:00:15

Re: Autochown: inotify-based file attribute manager

#22 2013-02-13 21:12:20

Re: Autochown: inotify-based file attribute manager

#23 2013-02-13 23:24:08

Re: Autochown: inotify-based file attribute manager

#24 2013-04-25 13:07:43

Re: Autochown: inotify-based file attribute manager

#25 2013-04-25 13:13:09

Re: Autochown: inotify-based file attribute manager

Board footer