Missing links
Just noticed the following missing links (and they are quite recent, presumably following some update or other). The last one listed seems particularly weird (redundant?). /usr/i686-pc-mingw32/lib/crt1.o -> /usr/i686-pc-mingw32/sys-root/mingw/lib/crt1.o /usr/i686-pc-mingw32/lib/dllcrt1.o -> /usr/i686-pc-mingw32/sys-root/mingw/lib/dllcrt1.o /usr/i686-pc-mingw32/lib/gcrt1.o -> /usr/i686-pc-mingw32/sys-root/mingw/lib/gcrt1.o /usr/share/man/man1/csh.1 -> tcsh.1 /usr/share/man/man1/red.1 -> ed.1 /usr/share/terminfo/6a/jfbterm -> ../6b/kon /usr/share/terminfo/terminfo -> ../share/terminfo Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Christopher, Thanks for your reply. Christopher Faylor wrote: > > On Wed, Jul 23, 2014 at 08:08:07PM +0400, Andrey Repin wrote: > >Greetings, D. Boland! > >> Cygwin security will be done for in the long run. Why not make the leap and > >> show MS admins/developers how it should be done? > > > >You really think they are all idiots?... Like, really? > > Sure, why not. MS admins/developers are all idiots who are apparently > supposed to be taught by Cygwin developers who have been getting it > wrong for many years until being correct by the OP. > > To the OP: If you want to start a dialog, do research and ask questions. > Don't just assume that you understand everything and can provide insight > that no one else has thought of. > > cgf I didn't say 'idiots', but I did LOL at Andrey's suggestion. Andrey, I'm beginning to like you. By the way, your english really isn't that bad. What I meant was that MS dicided to take away impersonation privileges from the SYSTEM user, without educating admins/developers about the new model or alternatives for SYSTEM. I searched the web extensively for an explanation on the newly imposed restriction. I didn't find one yet. Only vague advice to not start services using the local System account: "Minimize the use of the Local System account on the site servers and site systems by not installing other services that use the Local System account. This ensures that other processes cannot take advantage of the enhanced privileges of the systems computer account, accessing Configuration Manager 2007 files and data through those other systems." -- source: http://technet.microsoft.com/en-us/library/bb680595.aspx So I have to assume that it was to enhance Windows security. That is not far-fetched, since the SYSTEM "user" is totally unrestricted and not suited to be exposed directly to users from the outside. I also have to assume that what they mean by "not installing other services that use the Local System account" is to create a new user and running a service on behalf of it. Here's how they explain how to configure MS SQL Server (which uses impersonation), but without explaining the underlying security model for services: http://msdn.microsoft.com/en-us/library/ms143504.aspx The only reference I can find about the service security model are the terms "minimum rights" and "minimum privileges". In Linux, the daemon security model is well-known and can be implemented by running as an 'unprivileged user'. Sendmail uses this idea extensively. Again, the only option I have at this moment is to run the Sendmail user (smmsp) as an Administrator, so it can do impersonation. But this does *not* constitute 'minimum privileges', nor does this make the Sendmail user run as an 'unprivileged user'. The preferred solution is to only *start* Sendmail with a privileged user, let's say 'cyg_server'. Now Sendmail can switch to the 'smmsp' user and be running totally unprivileged, only having access to its mail queue directory. But after configuring Sendmail this way, it starts to complain about not having access permissions, because it detects it was not started with the root user (getuid != 0). So, my original question was: can the Cygwin function 'getuid' be made to return '0' if the program is running as the SYSTEM user? But because SYSTEM cannot be used anymore, Corinna suggests to use 'cyg_server' instead and put checks for administrator rights in the Sendmail source. In my reply to her in this thread, I rephrased my question: can the Cygwin function 'getuid' be made to return '0' if the program is running as the SYSTEM user or is running with administrator rights? Cincerely, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug executing "write" at Cygwin 1.7.31-2
Hello,
I am preparing the new version 4.0.1 of Varnish.
I am using a Windows 8.1 machine, with all hotfix installed.
I have updated cygwin to 1.7.31-2 and launch Varnish package tests and
some failed at "write" function.
After some investigations downloading snapshots, I have verified that:
* Varnish tests works fine using 20140625 snapshot, downloaded from
http://cygwin.com/snapshots/x86_64/cygwin1-20140625.dll.xz
* Varnish tests fails using the next snapshot: 20140707, downloaded
from http://cygwin.com/snapshots/x86_64/cygwin1-20140707.dll.xz
When installing 20140707 snapshot or 1.7.31-2 release, all the
problematic tests fails with similar messages:
1. s11.5 Write failed: (212992 vs 1048234) No error
2. *s11.7 Write failed: (212992 vs 1572908) No error
3. *s11.7 Write failed: (212992 vs 59) No error
This message is written by following code, at vtc_http.c file:
/**
* Finish and write the vsb to the fd
*/
static void
http_write(const struct http *hp, int lvl, const char *pfx)
{
ssize_t l;
AZ(VSB_finish(hp->vsb));
vtc_dump(hp->vl, lvl, pfx, VSB_data(hp->vsb), VSB_len(hp->vsb));
l = write(hp->fd, VSB_data(hp->vsb), VSB_len(hp->vsb));
if (l != VSB_len(hp->vsb))
vtc_log(hp->vl, hp->fatal, "Write failed: (%zd vs %zd) %s",
l, VSB_len(hp->vsb), strerror(errno));
}
hp->fd is a TCP socket and it seems that "write" function is only
writing 212992 bytes for some strange reason
I will continue doing some investigations, but it seems that the problem
is caused by some modification of that 20140707 snapshot:
https://cygwin.com/snapshots/x86_64/winsup-diffs-20140625-20140707
Thank you,
Jorge
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Core dump on 32-bit Cygwin if program calls dlopen
2014-07-22 15:20 GMT+02:00 Corinna Vinschen wrote: > On Jul 22 13:59, Jon TURNEY wrote: >> On 22/07/2014 09:27, Corinna Vinschen wrote: >> >On Jul 17 20:24, Corinna Vinschen wrote: >> >>On Jul 17 16:31, Jon TURNEY wrote: >> >>>On 17/07/2014 08:37, Corinna Vinschen wrote: >> It's the libgcc DLL which gives us grief, so a new libgcc package is >> sufficent, afaics. We should check if this DLL fixes the problem and >> then make it "curr" soon, I think. >> >>> >> >>>I briefly tested this other patch with my test case from the mail above, >> >>>and >> >>>it doesn't seem to help. >> >>>[...] >> >>I asked DJ to take another look, but I guess ultimately we need the >> >>attention of one of the GCC Windows maintainers. Kai Tietz seems to be >> >>unavailable right now, unfortunately. >> > >> >Looks like I totally misunderstood DJ's patch. The patch does *not* >> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file >> >which is statically linked into the executable. >> > >> >That means, to fix the issue, you don't have to replace libgcc, you >> >have to recompile the executable against the new crtbegin.o. >> > >> >DJ still claims his patch is the correct one. The simple testcase >> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to >> >him. >> >> Sorry, I hadn't tested it correctly. > > No worries, this was my fault. Talking about building a new libgcc > rather than building a new crtbegin.o was bound to lead everyone > off track :| > >> Building my test with an updated crtbegin.o as well, my test case is fixed. > > Nice! > >> I agree this patch seems better than my suggested one, as it makes crtbegin >> do the right thing in the face of unbalanced libgcc load/unload, rather than >> attempting to balance the libgcc load/unload as mine does. > > Ok. I CC'ed DJ so he knows all is good, and then we probably need a > windows GCC maintainer to approve the patch I guess. Kai? Ping? > Hi Corinna As I we spoke yesterday on irc, I took already a look to DJ's patch and it is sensible. If DJ sends patch upstream to gcc's ML, and put me CC, I will review it asap. Thanks, Kai -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Greetings, D. Boland! > What I meant was that MS dicided to take away impersonation privileges from > the > SYSTEM user, without educating admins/developers about the new model or > alternatives > for SYSTEM. There's no "model", there's "rights" or "capabilities", or "privileges". > I searched the web extensively for an explanation on the newly imposed > restriction. > I didn't find one yet. Because there's none. > Only vague advice to not start services using the local System account: > "Minimize the use of the Local System account on the site servers and site > systems > by not installing other services that use the Local System account. This > ensures > that other processes cannot take advantage of the enhanced privileges of the > systems computer account, accessing Configuration Manager 2007 files and data > through those other systems." Exactly that. What is unclear? > So I have to assume that it was to enhance Windows security. It's to enhance operating security of default installations. "Windows security" as a "model" isn't changed in even slightest way. > That is not far-fetched, since the SYSTEM "user" is totally unrestricted and > not suited to be exposed directly to users from the outside. > I also have to assume that what they mean by "not installing other services > that use > the Local System account" is to create a new user and running a service on > behalf of > it. > Here's how they explain how to configure MS SQL Server (which uses > impersonation), > but without explaining the underlying security model for services: > http://msdn.microsoft.com/en-us/library/ms143504.aspx > The only reference I can find about the service security model are the terms > "minimum rights" and "minimum privileges". It's not "model" again. It's privilege separation. > In Linux, the daemon security model is well-known and can be implemented by > running > as an 'unprivileged user'. Sendmail uses this idea extensively. That's no different here. The point you miss is that in Windows you don't have single "privileged user", which is just a long synonym for "root" in Linux world. You have exactly "privileged users", as in "users that have privileges above and beyond". > Again, the only option I have at this moment is to run the Sendmail user > (smmsp) as > an Administrator, so it can do impersonation. You contradicting yourself. Mere lines above you said your Linux user is unprivileged, now you want to do impersonation. Which is only possible for privileged user. > But this does *not* constitute 'minimum privileges', nor does this make the > Sendmail user run as an 'unprivileged user'. That because... see above. > The preferred solution is to only *start* Sendmail with a privileged user, > let's say > 'cyg_server'. Now Sendmail can switch to the 'smmsp' user and be running > totally > unprivileged, only having access to its mail queue directory. Right. > But after configuring Sendmail this way, it starts to complain about not > having > access permissions, because it detects it was not started with the root user > (getuid > != 0). Look, here you have a problem, that you don't want to understand it seems. Checking for 'privileged user' is not the same as checking for 'uid == 0'. > So, my original question was: can the Cygwin function 'getuid' be made to > return '0' No. A blatant and angry one. There's more systems, than Linux, and not all of them employ same security model, nor their model can be closely approximated to the one in Linux. > if the program is running as the SYSTEM user? But because SYSTEM cannot be > used > anymore, Corinna suggests to use 'cyg_server' instead and put checks for > administrator rights in the Sendmail source. > In my reply to her in this thread, I rephrased my question: can the Cygwin > function > 'getuid' be made to return '0' "Can", "will" and "want" (or in our case "should") are three completely different terms. The fact their areas intersect sometimes is a complete coincidence. > if the program is running as the SYSTEM user or is > running with administrator rights? No. If you want to do the right thing, do it right. -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.07.2014, <16:05> Sorry for my terrible english...
Re: Bug executing "write" at Cygwin 1.7.31-2
On Jul 24 14:22, jdzstz wrote: > Hello, > > I am preparing the new version 4.0.1 of Varnish. > I am using a Windows 8.1 machine, with all hotfix installed. > > I have updated cygwin to 1.7.31-2 and launch Varnish package tests and some > failed at "write" function. > > After some investigations downloading snapshots, I have verified that: > > * Varnish tests works fine using 20140625 snapshot, downloaded from >http://cygwin.com/snapshots/x86_64/cygwin1-20140625.dll.xz > * Varnish tests fails using the next snapshot: 20140707, downloaded >from http://cygwin.com/snapshots/x86_64/cygwin1-20140707.dll.xz > > When installing 20140707 snapshot or 1.7.31-2 release, all the problematic > tests fails with similar messages: > > 1. s11.5 Write failed: (212992 vs 1048234) No error > 2. *s11.7 Write failed: (212992 vs 1572908) No error > 3. *s11.7 Write failed: (212992 vs 59) No error Argh. Sorry about that. I missed to set a variable under a certain condition so a subsequent test failed too early. I prepared a bugfix and a new snapshot on http://cygwin.com/snapshots/ If it works for you, I create a bugfix'ed 1.7.31-3 release. Please report back. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1Dt1cNjSJb.pgp Description: PGP signature
Re: Core dump on 32-bit Cygwin if program calls dlopen
On Jul 24 15:08, Kai Tietz wrote: > 2014-07-22 15:20 GMT+02:00 Corinna Vinschen wrote: > > On Jul 22 13:59, Jon TURNEY wrote: > >> On 22/07/2014 09:27, Corinna Vinschen wrote: > >> >On Jul 17 20:24, Corinna Vinschen wrote: > >> >>On Jul 17 16:31, Jon TURNEY wrote: > >> >>>On 17/07/2014 08:37, Corinna Vinschen wrote: > >> It's the libgcc DLL which gives us grief, so a new libgcc package is > >> sufficent, afaics. We should check if this DLL fixes the problem and > >> then make it "curr" soon, I think. > >> >>> > >> >>>I briefly tested this other patch with my test case from the mail > >> >>>above, and > >> >>>it doesn't seem to help. > >> >>>[...] > >> >>I asked DJ to take another look, but I guess ultimately we need the > >> >>attention of one of the GCC Windows maintainers. Kai Tietz seems to be > >> >>unavailable right now, unfortunately. > >> > > >> >Looks like I totally misunderstood DJ's patch. The patch does *not* > >> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file > >> >which is statically linked into the executable. > >> > > >> >That means, to fix the issue, you don't have to replace libgcc, you > >> >have to recompile the executable against the new crtbegin.o. > >> > > >> >DJ still claims his patch is the correct one. The simple testcase > >> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to > >> >him. > >> > >> Sorry, I hadn't tested it correctly. > > > > No worries, this was my fault. Talking about building a new libgcc > > rather than building a new crtbegin.o was bound to lead everyone > > off track :| > > > >> Building my test with an updated crtbegin.o as well, my test case is fixed. > > > > Nice! > > > >> I agree this patch seems better than my suggested one, as it makes crtbegin > >> do the right thing in the face of unbalanced libgcc load/unload, rather > >> than > >> attempting to balance the libgcc load/unload as mine does. > > > > Ok. I CC'ed DJ so he knows all is good, and then we probably need a > > windows GCC maintainer to approve the patch I guess. Kai? Ping? > > > > Hi Corinna > > As I we spoke yesterday on irc, I took already a look to DJ's patch > and it is sensible. If DJ sends patch upstream to gcc's ML, and put > me CC, I will review it asap. Thanks a lot! JonY, any chance we could get a gcc package with the new crtbegin.o soon? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpx2AcgRQX7O.pgp Description: PGP signature
Re: The eternal uid issue
On Jul 24 08:52, D. Boland wrote:
> In your previous mail, you propose the following function to check for 'root'
> privileges, which an upstream maintainer could put in his code:
>
> int
> is_admin (uid_t uid)
> {
> #ifdef __CYGWIN__
> return [getgrouplist(uid, ...) contains group 544];
> #else [other platform]
> return [different test];
> #else
> return uid == 0;
> #endif
> }
>
> But this only introduces a new function which she has to put into multiple
> locations
> of the original code. So again, why not just modify the 'getuid' function in
> cygwin1.dll to return '0' if the current user is actually SYSTEM or one of the
> administrators?
>
> Then you have rock-solid emulation. I would not have to modify a single line
> of
> code.
You're kidding, right? What about code like this:
struct stat st;
stat("foo", &st);
if (st.st_uid != getuid ())
/*error*/
else
/*do something*/
I'm not saying that this is overly elegant coding, but just as you
expect that getuid() returns 0 for any admin, other applications will
expect that getuid() reflects reality.
Why don't you just override getuid in your application to serve the
applications needs?
#ifdef __CYGWIN__
#define getuid() CYG_getuid()
#endif
[...]
#ifdef __CYGWIN__
#undef getuid
uid_t
CYG_getuid ()
{
/* Return 0 for any admin user. */
if (/*getgroups() contains group 544*/)
return 0;
return getuid ();
}
But be careful. Just because there are multiple users with admin
permissions, that doesn't mean they all want their mail in the same
mailbox for user 0...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgphdqvD7fsKG.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] Updated: llvm/clang-3.4.2-1
On Jul 23 21:23, Angelo Graziosi wrote: > Corinna Vinschen wrote: > >The default for native Windows applications is the small code model > >[...] > >Therefore my > >collegue Kai Tietz provided GCC with implementations of a medium and > >large code model > > Gulp! Seems to re-read the Borland C++/TPascal manuals at the beginning of > the 1990s... only the huge model is missed (and tiny, obviously..) It's not that bad. It's just about using a trampolin for symbols not marked as dllimport/dllexport. The medium and large code models allow to drop the requirement to mark symbols as DLL symbols and still link the executable correctly, even in the big 44 bit address room of x86_64. The problem stems from the fact that the x86_64 64 bit instruction set doesn't know relative jumps with more than 31 bit displacement. The only really bad problem is, sombody has to create a patch for clang... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpf7gQb7xLho.pgp Description: PGP signature
Re: Missing links
On Jul 24 09:22, Fergus Daly wrote: > Just noticed the following missing links (and they are quite recent, > presumably following some update or other). > The last one listed seems particularly weird (redundant?). > /usr/i686-pc-mingw32/lib/crt1.o -> > /usr/i686-pc-mingw32/sys-root/mingw/lib/crt1.o > /usr/i686-pc-mingw32/lib/dllcrt1.o -> > /usr/i686-pc-mingw32/sys-root/mingw/lib/dllcrt1.o > /usr/i686-pc-mingw32/lib/gcrt1.o -> > /usr/i686-pc-mingw32/sys-root/mingw/lib/gcrt1.o The maintainer for mingw.org disappeared, but mingw.org is rather not in the best of conditions. You're better off switching to the mingw32-w64 toolchains. > /usr/share/man/man1/csh.1 -> tcsh.1 > /usr/share/man/man1/red.1 -> ed.1 Bugs. The csh symlink is mine, but I forgot that the man pages are gzip'ed for a while now. I'll fix that in the next tcsh package (a new upstream version is upcoming). It's the same for red.1 vs. ed.1, I guess. > /usr/share/terminfo/6a/jfbterm -> ../6b/kon This one is fine on my installation. ../6b/kon exists. > /usr/share/terminfo/terminfo -> ../share/terminfo I don't have that symlink in my installation. PEBCAK error, maybe? ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfEWRkNtThH.pgp Description: PGP signature
Emacs flyspell mode can't get process lock
When opening a .txt file in Emacs, I have flyspell-mode enabled by default. This requires Emacs to start an aspell process. This has been failing regularly with the following error: 0 [sig] emacs 1160 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0 580 [sig] emacs 1160 proc_subproc: couldn't get proc lock. what 5, val 1 Is there some suggested way to debug this? I tried the 07/24 snapshot of cygwin1.dll at Ken Brown's suggestion but to no avail. My cygcheck.out file is attached. I've -- Jim Reisert AD1C, , http://www.ad1c.us cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
Hi Corinna,
Corinna Vinschen wrote:
> > But this only introduces a new function which she has to put into multiple
> > locations
> > of the original code. So again, why not just modify the 'getuid' function in
> > cygwin1.dll to return '0' if the current user is actually SYSTEM or one of
> > the
> > administrators?
> >
> > Then you have rock-solid emulation. I would not have to modify a single
> > line of
> > code.
>
> You're kidding, right?
Haha. I must admit that I was not kidding. I got stuck with the idea that
"there can
only be one".
> What about code like this:
>
> struct stat st;
> stat("foo", &st);
> if (st.st_uid != getuid ())
> /*error*/
> else
> /*do something*/
>
> I'm not saying that this is overly elegant coding, but just as you
> expect that getuid() returns 0 for any admin, other applications will
> expect that getuid() reflects reality.
>
> Why don't you just override getuid in your application to serve the
> applications needs?
>
> #ifdef __CYGWIN__
> #define getuid() CYG_getuid()
> #endif
>
> [...]
>
> #ifdef __CYGWIN__
> #undef getuid
> uid_t
> CYG_getuid ()
> {
> /* Return 0 for any admin user. */
> if (/*getgroups() contains group 544*/)
> return 0;
> return getuid ();
> }
>
> But be careful. Just because there are multiple users with admin
> permissions, that doesn't mean they all want their mail in the same
> mailbox for user 0...
Thanks for the overloading code. I already tested it. Now I can leave the
Sendmail
code (almost) unchanged. Thanks also for the time you put into this. I hope the
RedHat people pay you well.
I have Sendmail ready to be released, but only the 'crude' version (running as
an
admin user). I'd like to go for the preferred solution (starting as admin,
switching
to unprivileged). The uid issue is sorted. But to get it there, I have one final
problem to solve.
Sendmail checks if the user's home directories are group- or world writable. It
does
this with 'stat'. If Sendmail is running in 'crude' mode (main program and
children
running as the Sendmail 'smmsp' user, made admin), stat returns the right file
mode
for my home directory (rwxr-xr-x). The email is delivered.
If I have Sendmail running in preferred mode (main program as cyg_server,
children
running as 'smmsp', removed from admin group), stat returns the wrong mode
(rwxrwxrwx). As a consequence, Sendmail refuses to deliver email.
Can I do anything about this?
Cincerely,
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs flyspell mode can't get process lock
On 7/24/2014 4:56 PM, Jim Reisert AD1C wrote: When opening a .txt file in Emacs, I have flyspell-mode enabled by default. This requires Emacs to start an aspell process. This has been failing regularly with the following error: 0 [sig] emacs 1160 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0 580 [sig] emacs 1160 proc_subproc: couldn't get proc lock. what 5, val 1 Exactly how do you have flyspell-mode enabled by default? I just customized 'text-mode-hook' and chose the option 'turn-on-flyspell'. It works fine. I've exited and restarted emacs several times to be sure. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Core dump on 32-bit Cygwin if program calls dlopen
On 7/24/2014 21:45, Corinna Vinschen wrote: > > JonY, any chance we could get a gcc package with the new crtbegin.o > soon? Yes, I just uploaded gcc-4.8.3-2, I'll announce once it hits the mirrors. signature.asc Description: OpenPGP digital signature
Re: The eternal uid issue
On 7/24/2014 5:42 PM, D. Boland wrote: > Hi Corinna, > > Corinna Vinschen wrote: >> But be careful. Just because there are multiple users with admin >> permissions, that doesn't mean they all want their mail in the same >> mailbox for user 0... Things are actually worse than Corinna and others have described. The SYSTEM account is a built-in local machine account that by default is granted certain permissions but those permissions are configurable. There is a built-in Administrator account which everyone is taught to never use There are two default groups "Administrators" and "Domain Administrators" whose members are considered to be administrators but whose logon sessions run in a restricted mode which is tighter in many regards than standard users UNLESS the process running as that user is granted "elevated" access. Simply working off the user's SID or GIDs to make decisions are often going to result in failures that appear to your users as unpredictable. > Thanks for the overloading code. I already tested it. Now I can leave the > Sendmail > code (almost) unchanged. Thanks also for the time you put into this. I hope > the > RedHat people pay you well. > > I have Sendmail ready to be released, but only the 'crude' version (running > as an > admin user). I'd like to go for the preferred solution (starting as admin, > switching > to unprivileged). The uid issue is sorted. But to get it there, I have one > final > problem to solve. On all modern versions of Windows the accounts that are members of the Administrators and Domain Administrators accounts are going to run unprivileged. In the Windows world background daemons (aka services) should be assigned their own service account that is granted the minimum set of privileges required. Windows permissions are much more fine grained than POSIX and this gives you a great deal of control. Shedding privileges can be done by a privileged process by replacing its process (or thread access tokens) with a more restricted version. > Sendmail checks if the user's home directories are group- or world writable. > It does > this with 'stat'. If Sendmail is running in 'crude' mode (main program and > children > running as the Sendmail 'smmsp' user, made admin), stat returns the right > file mode > for my home directory (rwxr-xr-x). The email is delivered. On Windows file systems (as with many UNIX network file systems, think AFS as one example) the UNIX mode is not going to have much value. What matters are the entries in the access control list and that is what should be checked and manipulated. Cygwin can't turn a non-POSIX file system into a POSIX file system no matter how hard it tries. > If I have Sendmail running in preferred mode (main program as cyg_server, > children > running as 'smmsp', removed from admin group), stat returns the wrong mode > (rwxrwxrwx). As a consequence, Sendmail refuses to deliver email. The UNIX mode cannot describe the fine grained permissions of the access control language for the file system. > Can I do anything about this? Other members of this group might have some additional suggestions on how to remove checks but if you really want secure delivery of e-mail on a Windows file system you will need to write code that is capable of understanding the capabilities of the file system. Just as you would on UNIX if the home directory was in a network file system that relied upon GSS/Kerberos network credentials and Access Control Lists instead of UNIX mode for access control. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
