unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: jari <jari.aalto@cante.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 10257@debbugs.gnu.org
Subject: bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive)
Date: Tue, 13 Dec 2011 18:26:28 +0200	[thread overview]
Message-ID: <20111213162628.GB22678@picasso.cante.net> (raw)
In-Reply-To: <E1RaTZh-0006H7-3R@fencepost.gnu.org>

On 2011-12-13 09:43, Eli Zaretskii wrote:
| > | So why don't you ask on the Cygwin list whether access() and
| > | euidaccess() can be taught to give the "right" answer for files on
| > | such drives.  Or maybe the question is simply whether Cygwin can be
| > | taught to determine the correct UID.
| > 
| > Sure, but because The network drive is not part of Windows Domain, I'm
| > afraid Cygwin has any means to determine what the correct UID or GID
| > would be are as they have no correspondence on the Windows side.
| 
| ??? As long as the network drive is mounted using Windows APIs (which
| must be the case), the NT security features should be fully supported
| for it.  That includes the user and group IDs of every file.  So why
| does Cygwin's `stat' return 4294967295 (which AFAIU is a fancy way of
| saying -1) for UID and GID of these files?

Response from Cygwin list:

    >     $ ls -la /cygdrive/z/tmp/test-epackage.el
    >     -rwxr--r-- 1 ???????? ???????? 437 Dec  9 20:02 /cygdrive/z/tmp/test-epackage.el

    It's not a bug.

    If you use winbind and the user accounts are correctly mapped to
    Windows accounts, then you would see the Cygwin UIDs/GIDs
    correspoding to the SID of the AD user account.

    If you don't do that, there's only an invisible mapping from the
    Windows SID to the Unix uid/gid.  The actual UNIX account has not
    the same mapping back to the Windows SID.  Instead, the SID
    returned from Samba to Windows is a fake SID S-1-22-1-UnixUID or
    S-1-22-2-UnixGID.  (..)

The rest goes into details for setting 1:1 UID, GID mapping.

Still,

     - The mapped drive can be written to without any extra 1:1 GUID,UID
       configuration.
     - Under Cygwin, should Emacs rely on unreliable[*] UID, GID?
     - Is there need for this extra prompt? The protective
       nature turned into nightmare.

Much better would be to give control back to the user:

  (setq write-file-interactive-confirmation-flag nil)

This doesn't affect Emacs's ability to signal an error on write
failure.

Jari

[*] Which depend on specific environment and settings user has. The
1:1 setting gets interesting for N servers that may have different
UID, GID settings for the same user names; as they may not all be part
of the same domain.





  parent reply	other threads:[~2011-12-13 16:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-09 18:23 bug#10257: 23.3.1 Cygwin: network drives - file is write protected (false positive) Jari Aalto
2011-12-09 20:33 ` Ken Brown
2011-12-10  9:58   ` jaalto
2011-12-13 12:18     ` Ken Brown
2011-12-13 14:00       ` jari
2011-12-13 14:43         ` Eli Zaretskii
2011-12-13 15:12           ` Ken Brown
2011-12-13 19:27             ` Stefan Monnier
2011-12-13 20:16               ` Ken Brown
2011-12-14  2:54                 ` Stefan Monnier
2011-12-14  3:27                   ` Ken Brown
2011-12-14  8:01                     ` Jari Aalto
2011-12-14  8:35                       ` Eli Zaretskii
2011-12-14 12:24                         ` Ken Brown
2011-12-14 12:55                           ` Ken Brown
2011-12-14 13:10                             ` Eli Zaretskii
2011-12-14 14:19                               ` Ken Brown
2011-12-14 14:47                                 ` jari
2011-12-14 17:30                                 ` Eli Zaretskii
2011-12-14 17:57                                   ` Ken Brown
2011-12-15  2:43                                     ` Ken Brown
2011-12-15  2:53                                       ` Ken Brown
2011-12-15  3:19                                         ` Ken Brown
2011-12-15  4:04                                       ` Eli Zaretskii
2011-12-15 14:42                                         ` Ken Brown
2011-12-16 19:37                                           ` Ken Brown
2011-12-16 19:46                                             ` Eli Zaretskii
2011-12-16 23:15                                             ` Stefan Monnier
2011-12-17 17:08                                               ` Ken Brown
2011-12-14 14:15                             ` jari
2011-12-14 14:29                               ` Ken Brown
2011-12-14 14:43                                 ` jari
2011-12-14 17:21                                 ` Eli Zaretskii
2011-12-14 17:23             ` Richard Stallman
2011-12-13 16:26           ` jari [this message]
2011-12-13 16:52             ` Ken Brown
2011-12-13 17:48               ` jari
2011-12-13 17:48             ` Eli Zaretskii
2011-12-13 18:05               ` jari
2011-12-13 18:36                 ` Eli Zaretskii
2011-12-15 14:44           ` Jason Rumney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111213162628.GB22678@picasso.cante.net \
    --to=jari.aalto@cante.net \
    --cc=10257@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).