Potential Enhancement Of 'noacl'?

Potential Enhancement Of 'noacl'?

[Bryan Berns]

Wasn't sure which mailing list I should throw this on so I apologize
if this is the wrong one -- just let me know for future purposes.

At least for my internal use, I plan to create a patch that will allow
me to conditionally force a permission set for a particular mount
point -- like an enhanced "noacl".  I was thinking about adding an
option after noacl[=XXX] where XXX would force XXX as the returned
permissions for any file on that mount point.

Why would someone want to do this crazy thing?  In short, I continue
to struggle with the current Cygwin permissions handling for certain
drives where programs do sanity checks on group readability (e.g.,
ssh).  Our drives have ACEs for various admin groups.  Regardless of
various philosophical viewpoints on file system administration, that's
how it is for us and it's not going to change.  I believe a select
group of others might be in this same boat.

The only other alternative that would work for us to would be read a
custom list of SIDS to ignore in group permission calculations but I
already know Corinna is not a fan of that.

Would this (the noacl thing) be something that we'd be potentially
willing to incorporate into the codebase?  If I know ahead of time,
I'll make sure I address some other artifacts (user guide
documentation, etc).

Thanks,

Bryan

Re: Potential Enhancement Of 'noacl'?

[Corinna Vinschen]

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

On Apr 17 14:11, Bryan Berns wrote:
> Wasn't sure which mailing list I should throw this on so I apologize
> if this is the wrong one -- just let me know for future purposes.
> 
> At least for my internal use, I plan to create a patch that will allow
> me to conditionally force a permission set for a particular mount
> point -- like an enhanced "noacl".  I was thinking about adding an
> option after noacl[=XXX] where XXX would force XXX as the returned
> permissions for any file on that mount point.

I'm not out-of-the-box enthusiastic about it...

> Why would someone want to do this crazy thing?  In short, I continue
> to struggle with the current Cygwin permissions handling for certain
> drives where programs do sanity checks on group readability (e.g.,
> ssh).

That puzzles me.  OpenSSH is upstream Cygwin-aware, and the code skips
permission checks on files if the underlying filesystem does not support
permissions (e.g. noacl or FAT FS).  What problem do you have in real
life with noacl?

> Would this (the noacl thing) be something that we'd be potentially
> willing to incorporate into the codebase?  If I know ahead of time,
> I'll make sure I address some other artifacts (user guide
> documentation, etc).

I'd like to discuss this first..  But, alas, Red Tape rulez.  If you
want to provide code, you'll have to sign a copyright assignment.
Please have a look at https://cygwin.com/contrib.html.  It contains some
description and a pointer to the assignment text.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Potential Enhancement Of 'noacl'?

[Bryan Berns]

On Fri, Apr 17, 2015 at 2:56 PM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> On Apr 17 14:11, Bryan Berns wrote:
>
>> Why would someone want to do this crazy thing?  In short, I continue
>> to struggle with the current Cygwin permissions handling for certain
>> drives where programs do sanity checks on group readability (e.g.,
>> ssh).
>
> That puzzles me.  OpenSSH is upstream Cygwin-aware, and the code skips
> permission checks on files if the underlying filesystem does not support
> permissions (e.g. noacl or FAT FS).  What problem do you have in real
> life with noacl?
>

Hmm... good question. I honestly not sure I put it to a practical test
-- I just saw it was reporting group read via 'ls -l' and stopped
there.  I'll give it a shot on Monday.  You may have made my day.... I
really didn't *want* to do what I was proposing :P

Re: Potential Enhancement Of 'noacl'?

[Corinna Vinschen]

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

On Apr 17 15:02, Bryan Berns wrote:
> On Fri, Apr 17, 2015 at 2:56 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > On Apr 17 14:11, Bryan Berns wrote:
> >
> >> Why would someone want to do this crazy thing?  In short, I continue
> >> to struggle with the current Cygwin permissions handling for certain
> >> drives where programs do sanity checks on group readability (e.g.,
> >> ssh).
> >
> > That puzzles me.  OpenSSH is upstream Cygwin-aware, and the code skips
> > permission checks on files if the underlying filesystem does not support
> > permissions (e.g. noacl or FAT FS).  What problem do you have in real
> > life with noacl?
> >
> 
> Hmm... good question. I honestly not sure I put it to a practical test
> -- I just saw it was reporting group read via 'ls -l' and stopped
> there.  I'll give it a shot on Monday.  You may have made my day.... I
> really didn't *want* to do what I was proposing :P

Heh :)

If you still find a problem when using ssh on a noacl filesystem, I'd
lean towards fixing ssh in that case.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]