This article will show you how to encrypt the filesystem and mount it with ACL (Access Control Lists), which gives you rights beyond the traditional read (r), write (w), and execute (x) permissions for the three user groups “file”, “owner”, and “other”.
I thought the three groups were User, Group, and Other?
Err it’s Owner,Group,User,therefore chown and chgrp exist.
Jim got it more right that You
It’s Owner, Group, Other.
isn’t the loopback module being depreciated because it’s not being maintained? I think I read that somewhere recently..
Owner + Group + World == All
In fact, it’s UGW. User not Owner. Sorry.
“Other” is also used for the third thing.
I dont think so. where did you read that stuff
——————————————————-
First, you want to create a 20MB file by executing the following command:
$ dd if=/dev/zero of=disk-image count=40960
——————————————————-
This step can be made more intuitive by boosting block size from 2048 bytes to 1MB with the ‘bs’ flags:
$ dd if=/dev/zero of=disk-image bs=1M count=20
I was looking at acl in reiserfs a year ago, but then neither Gnome or KDE had integrated support in their filemanager.
Does anyone know state of acl support in Gnome/KDE?
As far as I can see there hasn’t been any progress on that part.
Interesting, but last time I did that I was using device mapper and dm-crypt. I guess it achieves the same thing at the end of it; part of the beauty of Linux I suppose, that there’s always another way to do something!
THat being said, I went with dm-crypt because I heard cryptoloop was going to be deprecated in favour of it; anyone else heard this?
Missed Chris’ post on the way through. I think I read it on kerneltrap? Can’t really remember though.
Nope. Last time I heard Konqueror would blow away ACL’s when copying. Not sure how well Nautilus copes with them. Before Gnome has it, generic ACL support will need to be built into GnomeVFS first, to support any kind of ACL. Then the POSIX ACL’s would be implemented in GnomeVFS, then finally in Nautilus. That’s how I understand things would have to be done to get it included into Nautilus.
Doesn’t seem like a very big deal to me though. System administrators should be managing permissions. Though the whole blowing ACL’s away would be a problem.
How would you set it up so a user could create and edit files but could not delete existing files?
Here is the article about loopback being depreciated and what you should use instead.
http://www.linux.com/article.pl?sid=04/06/07/2036205
@Antonis: The article you mentioned covers cryptoloop and not loopback.
From the cmod man page:
A combination of the letters ‘ugoa’ controls which users’ access to the file will be changed:
the user who owns it (u),
other users in the file’s group (g),
other users not in the file’s group (o),
or all users (a).
So, while “owner group other” works it doesn’t match the “ugo” flags for chown. I always use “user group other”
I still wonder why so many ppl talk bells and whistles about ACLs, when they still have no clue on how to properly use the UGO paradygm.
Before using something complex first make sure you know how to use something simpler!
There is not much one can’t do with UGO really, if you know how to useit.
Of course it’s always about how much ppl want to learn.
This step can be made more intuitive by boosting block size from 2048 bytes to 1MB with the ‘bs’ flags:
$ dd if=/dev/zero of=disk-image bs=1M count=20
The mind boggles at why you didn’t use 20M blocks:
dd if=/dev/zero of=disk-image bs=20M count=1
I mean, if you’re going to “simplify”, why make it any more complicated than it needs to be ?
(Another benefit is that generally the bigger the block size used, the less time the dd takes).