lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Sharing directories on a multi-user *nix system


From: Greg Chicares
Subject: Re: [lmi] Sharing directories on a multi-user *nix system
Date: Mon, 23 Sep 2019 22:54:23 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 2019-09-23 21:27, Vadim Zeitlin wrote:
> On Mon, 23 Sep 2019 17:34:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Kim and I both want to use the /opt/lmi directory on our *nix
> GC> server. I'd never worked in a multi-user environment like this,
> GC> so I guessed that the solution might be ACLs, but...
> GC> 
> GC> The server seems not to enable acl:
> GC>   # tune2fs -l /dev/whatever
> GC>   invalid superblock
> 
>  I'm not sure why doesn't tune2fs work for you

Because it's XFS, I assume.

> could you have passed it
> the entire block device instead of the partition on which the file system
> is mounted?

I tried. Root directory is something like
  /dev/mapper/something_long
but, truncating that in various ways, I still got
  invalid superblock
from tune2fs.

> You can use "mount" to check for this.

The string 'acl' doesn't appear in the output.

> GC> but maybe it's on by default anyway? (this is XFS, so it should be)
> 
>  I'd just try using setfacl/getfacl to check that they work, if you want to
> use the ACLs.

But that feels like cheating. Anyway, no, I really don't want
to use ACLs.

> GC> Then I rethought that, and took a much simpler approach:
> GC> 
> GC> # Set up an 'lmi' group...
> GC> sudo groupadd lmi
> GC> # for U = my id and U = Kim's id both:
> GC> sudo usermod -a -G lmi ${U}
> GC> 
> GC> # if root already owns /opt (as is likely):
> GC> chown root:sudo /opt/lmi
>                ^^^^
>  This should have been "lmi".

Thanks for catching that. I did 'chown -R my_id:lmi .' in
all the directories that the lmi group should own.

> GC> chmod g+w /opt/lmi
> GC> ls -dl /opt/lmi
> GC> 
> GC> # ...and similarly for a /cache_for_lmi directory
> GC> 
> GC> Vadim, is there anything wrong with that?
> 
>  I don't think there is anything wrong with this as far allowing lmi to use
> /opt/lmi goes, i.e. I don't see any need for the more advanced ACLs here,
> when primitive group-based access control works just fine.

Thanks. Good to know.

>  However I think that ideally it should be possible to either replace
> /opt/lmi with an arbitrary directory (e.g. "make lmi_prefix=$HOME/lmi") or,
> at least, add support for the standard[*] DESTDIR variable (e.g. allow
> using "make DESTDIR=$HOME/tmp" to install in ~/tmp/opt/lmi). Under a normal
> Unix system it's really not normal to require access to any directory not
> belonging to the user just to build software.
> 
>  So while it could make sense to use /opt/lmi for e.g. the last officially
> released version, I'd really avoid using it for the normal builds done by
> different users -- this will result in conflicts/tears sooner or later.

I don't disagree. But this may not matter much. I'm just trying
to get the server to work. Once it does, I don't anticipate
using it often myself, because my own machine is more convenient.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]