Is it me or is it sudo?

Joel Rees joel.rees at gmail.com
Sat Mar 31 00:19:26 UTC 2012


On Sat, Mar 31, 2012 at 4:39 AM, James Wilkinson
<fedora at aprilcottage.co.uk> wrote:
> Reindl Harald wrote:
>> sounds more you do not understand what ACLs are for
>>
>> how could a private user group replace ACLs?
>> if you have different users and groups which needs
>> defined permissions you will always need ACLs because
>> chmod can only reflect the primary group
>>
>> for restrict access to a single user you need no ACL
>> chmod 600 does this for you
>
> It was in the old Red Hat Linux manuals (for example, section 6.4.1 of
> ftp://archive.download.redhat.com/pub/redhat/linux/7.3/en/doc/RH-DOCS/pdf-en/rhl-rg-en.pdf):
>
>    IF you want a shared directory (say a project directory) writeable
>    by some but not all users,
>    AND IF you don’t want to use ACLs¹,
>    THEN you need to have that directory and everything in it owned by a
>    suitable group (and set to be group-writeable).
>
>    IF you don’t want to have users having to play around with
>    ownership and permissions all the time,
>    THEN you need to have the setgid bit on the folder set (which makes
>    all new files and directories automatically have the appropriate
>    group)
>    AND you need to have umask set to 002 (which makes all new files and
>    directories group-writeable).
>
> From there, it follows that the easiest way to do this is to make 002
> the default umask, which means that all new files and directories
> created by normal users have these permissions. That means that if you
> want files that only their owner can write to, you need a per-user
> group.
>
> It makes perfect sense.
>
> James.
>
> ¹ This predated Linux ACLs, anyway.

And, of course, there are plenty of other ways to use per-user groups,
once you get your head around the idea that there is no one-to-one
relationship between user-ids and physical users.

One thing we didn't write back then, that we should have, was a
sub-user tool similar to the user tool --

subuser add/edit/delete/etc

It would have to incorporate user types, implicit/default quota
heuristics and other stuff that we didn't want to deal with then, but
find ourselves dealing with now, and it would use the setuid bit, so
each user could set up and get rid of his/her own private user/group
combos. Combine that with sudo, and we could have had sandboxed apps
years and years ago. (With a bit of work, but not near what ACLs and
their ilk cost us.)

That was the unix way, and we have parted from it to our detriment.

--
Joel Rees


More information about the users mailing list